# svn checkout suggestion

- Thread: https://externals.io/message/44993
- Original archive: https://news-web.php.net/php.internals/44993
- Started by Rasmus Lerdorf on 2009-07-16T22:07:15+00:00
- Messages: 14
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #44993 — Rasmus Lerdorf — 2009-07-16T22:07:15+00:00

URL: https://externals.io/message/44993#44993

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

---

## #44997 — Jani Taskinen — 2009-07-16T22:24:50+00:00

URL: https://externals.io/message/44993#44997 · In reply to: #44993

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

---

## #44999 — shire — 2009-07-16T22:45:07+00:00

URL: https://externals.io/message/44993#44999 · In reply to: #44997

Jani Taskinen wrote:
> Rasmus Lerdorf wrote:
> > […]
>
> 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

---

## #45000 — Jeff Griffiths — 2009-07-16T22:57:21+00:00

URL: https://externals.io/message/44993#45000 · In reply to: #44999

...
> 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

---

## #45001 — shire — 2009-07-16T23:02:31+00:00

URL: https://externals.io/message/44993#45001 · In reply to: #45000

Jeff Griffiths wrote:
> 
> ...
> > […]
>
> 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

---

## #45002 — Greg Beaver — 2009-07-16T23:09:04+00:00

URL: https://externals.io/message/44993#45002 · In reply to: #44993

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.
> 
> 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

<snip>

Rasmus this is brilliant.  You should add this to the manual for
posterity in your new shiny checkout of awesomeness.

:)
Greg

---

## #45003 — Rasmus Lerdorf — 2009-07-16T23:13:00+00:00

URL: https://externals.io/message/44993#45003 · In reply to: #45002

Greg Beaver wrote:
> Rasmus Lerdorf wrote:
> > […]
> 
> <snip>
> 
> 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

---

## #45004 — Pierre Joye — 2009-07-16T23:17:28+00:00

URL: https://externals.io/message/44993#45004 · In reply to: #44999

> Jani Taskinen 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 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

http://blog.thepimp.net | http://www.libgd.org

---

## #45006 — David Soria Parra — 2009-07-16T23:25:29+00:00

URL: https://externals.io/message/44993#45006 · In reply to: #45004

> 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.

---

## #45008 — shire — 2009-07-17T00:01:05+00:00

URL: https://externals.io/message/44993#45008 · In reply to: #45004

Pierre Joye wrote:
> 
> > […]
>
> 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

---

## #45015 — Jani Taskinen — 2009-07-17T10:36:47+00:00

URL: https://externals.io/message/44993#45015 · In reply to: #44997

> Rasmus Lerdorf wrote:
> > […]
>
> 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

---

## #45017 — Davey Shafik — 2009-07-17T15:31:52+00:00

URL: https://externals.io/message/44993#45017 · In reply to: #45008

> Pierre Joye wrote:
> > […]
>
>
> 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

---

## #45020 — Lukas Kahwe Smith — 2009-07-17T19:24:26+00:00

URL: https://externals.io/message/44993#45020

> 
> ...
> > […]
>
> Is it that limited? I hadn't used it ( for a variety of reasons the  
> server is stuck on SVN 1.4 or something ). We DO  use the svnmerge  
> tool for maintaining dev / stage / production branches for web apps  
> and versioned branches of things like Komodo. I guess I had assumed  
> form shire's reply that the svn 1.5.x merge support was a work- 
> alike, but I haven't ever attempted to use it myself.


there is a fat warning fo this in the manual. i dont quite get why .  
but that is the case atm.
also using merge tracking is only fun if everybody does it .. because  
if only some people use it .. they first have to figure out which  
things have not been merged via svn merge, as svn merge updates its  
metadata. when merging you can either mark an entire range of  
versisions as merged .. or just individually.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

---

## #45021 — Jeff Griffiths — 2009-07-17T20:06:50+00:00

URL: https://externals.io/message/44993#45021 · In reply to: #45020

...
> also using merge tracking is only fun if everybody does it .. because if
> only some people use it .. they first have to figure out which things
> have not been merged via svn merge, as svn merge updates its metadata.
> when merging you can either mark an entire range of versisions as merged
> .. or just individually.

I agree, we have a small team and all use the tool, so it works for us. 
php-src seems to have a larger number of committers and uses patches 
from a still-larger set of contributors, so using a tool like svnmerge 
would require some discipline and polite discussions about what is expected.

As mentioned, here is some documentation we wrote internally about using 
svnmerge with the openkomodo sources:

http://anisotropic.net/svnmerge.html

...it should give you an idea of the workflow we use. YMMV of course.

Jeff