One of the benefits of svn is that we can do cross-branch commit pretty
easily now and thus avoid multiple similar commits with annoying MFH/MFB
commit log messages that are hard to track.
Please don't attempt to check out all of php/php-src or pecl. I made
the mistake of checking out all of pecl and it was 3.4G because you get
copies of the code for every tag and branch and we have a bunch.
In order to do this better, I think the best way is to use the sparse
directory feature documented here:
http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html
It takes a bit of work to set up your checkout, but once you have done
it, it becomes easy to work with. Here are my steps to creating a
~/src/ directory with the parts of the repository I commit to:
Create initial top-level src dir
svn co http://svn.php.net/repository --depth empty src
Fetch the parts of the repository I care about
svn co http://svn.php.net/repository/php
http://svn.php.net/repository/pecl http://svn.php.net/repository/pear
http://svn.php.net/repository/phpdoc
http://svn.php.net/repository/systems http://svn.php.net/repository/web
--depth immediates src
Now, in php-src get all tags and branch names, but only
populate trunk and the PHP_5_2 and PHP_5_3 branches
cd ~/src/php/php-src
svn up branches tags --set-depth immediates
svn up trunk branches/PHP_5_2 branches/PHP_5_3 --set-depth infinity
In pecl get all tags and branch names,
but only checkout out trunk for each
cd ~/src/pecl
svn update * --set-depth immediates
svn update */tags */branches --set-depth immediates
svn update */trunk --set-depth infinity
Same idea for pear
cd ~/src/pear
svn update * --set-depth immediates
svn update */tags */branches --set-depth immediates
svn update */trunk --set-depth infinity
cd ~/src/pear/packages
svn update * --set-depth immediates
svn update */tags */branches --set-depth immediates
svn update */trunk --set-depth infinity
and pick up the remaining flat modules (systems, web)
cd ~/src
svn update */tags */branches --set-depth immediates
svn update */trunk --set-depth infinity
Once you have all this set up, you can then cd into any empty branch or
tag directory and run:
svn update --set-depth infinity
to fully populate that directory on demand.
and you can make changes across trunk and multiple branches and perhaps
even make the corresponding fixes in the phpdoc tree!
-Rasmus
Rasmus Lerdorf wrote:
One of the benefits of svn is that we can do cross-branch commit pretty
easily now and thus avoid multiple similar commits with annoying MFH/MFB
commit log messages that are hard to track.
I did a commit today on all 3 branches and it worked fine except for the fact
that no commit email was sent anywhere. I sent Gwynne a note about it, but so
that everyone knows too, don't commit anything like that until this is fixed..
--Jani
Jani Taskinen wrote:
Rasmus Lerdorf wrote:
One of the benefits of svn is that we can do cross-branch commit pretty
easily now and thus avoid multiple similar commits with annoying MFH/MFB
commit log messages that are hard to track.I did a commit today on all 3 branches and it worked fine except for the
fact that no commit email was sent anywhere. I sent Gwynne a note about
it, but so that everyone knows too, don't commit anything like that
until this is fixed..
Do we have a long-term plan of using actual merge commands/tools to merge our branches rather than duplicating commits or manually merging? I think this could speed up development and allow us to have more control over releases, versions, etc. I've seen cases in the past where changes fall through the cracks because they didn't get manually merged up/down. The ability to merge complete branches as a branch rather than many different commits could save some hastle assuming everyone follows the same commit/merge patterns.
-shire
...
Do we have a long-term plan of using actual merge commands/tools to
merge our branches rather than duplicating commits or manually merging?
I think this could speed up development and allow us to have more
control over releases, versions, etc. I've seen cases in the past where
changes fall through the cracks because they didn't get manually merged
up/down. The ability to merge complete branches as a branch rather than
many different commits could save some hastle assuming everyone follows
the same commit/merge patterns.
I'd suggest looking into the svnmerge tool:
http://www.orcaware.com/svn/wiki/Svnmerge.py
We use it quite a bit at ActiveState to migrate changes from developer
branches into trunk, and then into production. I would caution that the
merge actions might not be to everyone's taste, so you might want to
either encourage use or ban use depending on your preference.
We have some quite excellent Komodo-specific documentation a co-worker
wrote on how to use this tool for developer branches specifically; I
could see about providing this to someone if they want to try svnmerge out.
cheers, Jeff
Jeff Griffiths wrote:
...
Do we have a long-term plan of using actual merge commands/tools to
merge our branches rather than duplicating commits or manually merging?
I think this could speed up development and allow us to have more
control over releases, versions, etc. I've seen cases in the past where
changes fall through the cracks because they didn't get manually merged
up/down. The ability to merge complete branches as a branch rather than
many different commits could save some hastle assuming everyone follows
the same commit/merge patterns.I'd suggest looking into the svnmerge tool:
http://www.orcaware.com/svn/wiki/Svnmerge.py
We use it quite a bit at ActiveState to migrate changes from developer
branches into trunk, and then into production. I would caution that the
merge actions might not be to everyone's taste, so you might want to
either encourage use or ban use depending on your preference.We have some quite excellent Komodo-specific documentation a co-worker
wrote on how to use this tool for developer branches specifically; I
could see about providing this to someone if they want to try svnmerge out.
This sounds very similar to what the latest versions of SVN has already done, specifically merge tracking. You should now be able to use the 'svn merge' command and have it track changes for you across branches so you don't have to worry about merging the same rev twice etc.
-shire
Jani Taskinen wrote:
Rasmus Lerdorf wrote:
One of the benefits of svn is that we can do cross-branch commit pretty
easily now and thus avoid multiple similar commits with annoying MFH/MFB
commit log messages that are hard to track.I did a commit today on all 3 branches and it worked fine except for the
fact that no commit email was sent anywhere. I sent Gwynne a note about
it, but so that everyone knows too, don't commit anything like that
until this is fixed..Do we have a long-term plan of using actual merge commands/tools to merge
our branches rather than duplicating commits or manually merging? I think
this could speed up development and allow us to have more control over
releases, versions, etc. I've seen cases in the past where changes fall
through the cracks because they didn't get manually merged up/down. The
ability to merge complete branches as a branch rather than many different
commits could save some hastle assuming everyone follows the same
commit/merge patterns.
I doubt any tools can really help to automatically help to merge
changes from one branch to another (in php). However there are many
very good merging tools (with UI) out there to ease this process
(meld, winmerge, etc.).
Cheers,
Pierre
I doubt any tools can really help to automatically help to merge
changes from one branch to another (in php). However there are many
very good merging tools (with UI) out there to ease this process
(meld, winmerge, etc.).
In that case it's more that if we use merge tracking svn will recognize
what was already merged and try to find a common ancestor of the files
that will be merged, which usually results in less merge conflicts than
in CVS. Merge tracking just helps to minimize conflicts, but for sure,
from time to time we have to resolve conflicts ourselfs.
Pierre Joye wrote:
Jani Taskinen wrote:
Rasmus Lerdorf wrote:
One of the benefits of svn is that we can do cross-branch commit pretty
easily now and thus avoid multiple similar commits with annoying MFH/MFB
commit log messages that are hard to track.
I did a commit today on all 3 branches and it worked fine except for the
fact that no commit email was sent anywhere. I sent Gwynne a note about
it, but so that everyone knows too, don't commit anything like that
until this is fixed..Do we have a long-term plan of using actual merge commands/tools to merge
our branches rather than duplicating commits or manually merging? I think
this could speed up development and allow us to have more control over
releases, versions, etc. I've seen cases in the past where changes fall
through the cracks because they didn't get manually merged up/down. The
ability to merge complete branches as a branch rather than many different
commits could save some hastle assuming everyone follows the same
commit/merge patterns.I doubt any tools can really help to automatically help to merge
changes from one branch to another (in php). However there are many
very good merging tools (with UI) out there to ease this process
(meld, winmerge, etc.).
I don't see why this wouldn't be possible for PHP, but it would likely require us changing our current methodology for creating branches. Currently we make a branch and never merge it back, this is a bit different than what's seen in some other repositories. Specifically, we'd need to look at creating more branches for specific features and merging those back to a central version or trunk depending on the release it's planned to go out with.
One downside to this is that you usually need to have someone making sure things get synced back and forth (probably a RM), but this can be useful for keeping a development version relatively stable and encouraging cooperation between developers. Once a release goes out this stable code can then be merged back up-stream into the next major release or trunk etc. Obviously there's lots of details in here about how it can be structured and work, but I'm mostly asking about the high level "is this the direction we want to go".
This would basically mean you could make as many single commits as necessary for whatever you're working from without adversely affecting a lot of other branches or having to make up multiple commits for each bug. The downside being that to keep conflicts simple we should merge and merge often, and this could require the developer to do the "merge" on each commit or the RM doing a series of them and resolving any possible commits themselves. The first would be closer to what we do now, but would be simpler and allow merge-tracking. Would be interesting to know how some other large FOSS projects are handling this as well and what those experiences have been like. We also can't really do this for our current branches, it would probably need to be for all future versions.
-shire
Pierre Joye wrote:
Jani Taskinen wrote:
Rasmus Lerdorf wrote:
One of the benefits of svn is that we can do cross-branch commit
pretty
easily now and thus avoid multiple similar commits with annoying
MFH/MFB
commit log messages that are hard to track.
I did a commit today on all 3 branches and it worked fine except
for the
fact that no commit email was sent anywhere. I sent Gwynne a note
about
it, but so that everyone knows too, don't commit anything like that
until this is fixed..Do we have a long-term plan of using actual merge commands/tools
to merge
our branches rather than duplicating commits or manually merging?
I think
this could speed up development and allow us to have more control
over
releases, versions, etc. I've seen cases in the past where
changes fall
through the cracks because they didn't get manually merged up/
down. The
ability to merge complete branches as a branch rather than many
different
commits could save some hastle assuming everyone follows the same
commit/merge patterns.I doubt any tools can really help to automatically help to merge
changes from one branch to another (in php). However there are many
very good merging tools (with UI) out there to ease this process
(meld, winmerge, etc.).I don't see why this wouldn't be possible for PHP, but it would
likely require us changing our current methodology for creating
branches. Currently we make a branch and never merge it back, this
is a bit different than what's seen in some other repositories.
Specifically, we'd need to look at creating more branches for
specific features and merging those back to a central version or
trunk depending on the release it's planned to go out with.One downside to this is that you usually need to have someone making
sure things get synced back and forth (probably a RM), but this can
be useful for keeping a development version relatively stable and
encouraging cooperation between developers. Once a release goes out
this stable code can then be merged back up-stream into the next
major release or trunk etc. Obviously there's lots of details in
here about how it can be structured and work, but I'm mostly asking
about the high level "is this the direction we want to go".This would basically mean you could make as many single commits as
necessary for whatever you're working from without adversely
affecting a lot of other branches or having to make up multiple
commits for each bug. The downside being that to keep conflicts
simple we should merge and merge often, and this could require the
developer to do the "merge" on each commit or the RM doing a series
of them and resolving any possible commits themselves. The first
would be closer to what we do now, but would be simpler and allow
merge-tracking. Would be interesting to know how some other large
FOSS projects are handling this as well and what those experiences
have been like. We also can't really do this for our current
branches, it would probably need to be for all future versions.-shire
More importantly, the branch/merge support in SVN is limited to
temporary feature/bug branches. You branch, complete the feature/bug
fix, and then merge it in. After that, if you decide to carry on in
your branch, SVN's merge tracking cannot handle the tracking of
changes. You need to merge, delete, re-branch, carry on. This doesn't
work for say, the 5.3.x branch fixes getting pushed into trunk, the
5.3.x branch is toast as far as SVN is concerned once you merge the
first fix — quite useless.
- Davey
Rasmus Lerdorf wrote:
One of the benefits of svn is that we can do cross-branch commit pretty
easily now and thus avoid multiple similar commits with annoying MFH/MFB
commit log messages that are hard to track.I did a commit today on all 3 branches and it worked fine except for the
fact that no commit email was sent anywhere. I sent Gwynne a note about
it, but so that everyone knows too, don't commit anything like that
until this is fixed..
Uh..nevermind. Apparently the commit had failed (and I didn't notice it)
and thus never happened.. :D
--Jani
Rasmus Lerdorf wrote:
<snip>One of the benefits of svn is that we can do cross-branch commit pretty
easily now and thus avoid multiple similar commits with annoying MFH/MFB
commit log messages that are hard to track.Please don't attempt to check out all of php/php-src or pecl. I made
the mistake of checking out all of pecl and it was 3.4G because you get
copies of the code for every tag and branch and we have a bunch.In order to do this better, I think the best way is to use the sparse
directory feature documented here:http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html
Rasmus this is brilliant. You should add this to the manual for
posterity in your new shiny checkout of awesomeness.
:)
Greg
Greg Beaver wrote:
Rasmus Lerdorf wrote:
<snip>One of the benefits of svn is that we can do cross-branch commit pretty
easily now and thus avoid multiple similar commits with annoying MFH/MFB
commit log messages that are hard to track.Please don't attempt to check out all of php/php-src or pecl. I made
the mistake of checking out all of pecl and it was 3.4G because you get
copies of the code for every tag and branch and we have a bunch.In order to do this better, I think the best way is to use the sparse
directory feature documented here:http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html
Rasmus this is brilliant. You should add this to the manual for
posterity in your new shiny checkout of awesomeness.
I wouldn't call it brilliant. It takes 37 commands to do what I could
do in a couple in cvs.
-Rasmus