Questions about tag style branch/merge approach

[David Budworth <db...@eloan.com>]

Howdy y'all,

I have a couple of questions about using the tag style branch/merge 
approach where you create a merge point after each merge.

example:
svn cp svn://repo/trunk svn://repo/branches/mybranch
svn cp svn://repo/branches/mybranch svn://repo/merge-points/mybranch

svn co svn://repo/branches/mybranch wc

--edit files in wc--
svn commit wc

--merge back to the trunk--
svn co svn://repo/trunk
cd trunk && svn merge svn://repo/merge-points/mybranch 
svn://repo/branches/mybranch

All fine and dandy, works great, we don't have to remember version 
numbers.

Only problem is, how does one reset that merge point in an atomic 
fashion?

svn cp svn://repo/trunk svn://repo/merge-points/mybranch
will actually make a merge-points/mybranch/mybranch

We have been doing this as:
svn del svn://repo/merge-points/mybranch -m 'resetting mp'
svn cp svn://repo/trunk svn://repo/merge-points/mybranch


But it's not atomic, and if someone commits to the trunk after I do my 
trunk merge and before I re-create my merge point, I lose changes that 
the other person committed to trunk.
Plus it revs to repo three times for every trunk merge cycle (not a big 
deal, but mildly annoying)

example of what i'm talking about here:
person A merges to trunk, commits
person B merges to trunk, commits
person A deletes merge point
person A copies trunk to merge point

We lost the ability to merge person B's trunk change back to person A's 
branch.

Hope that made sense.

I suppose the best solution is to not do it like this, and just write 
some wrapper scripts to track the repo versions so we don't have to 
deal with all the copying around.
Manual tracking of versions on a person by person base isn't really an 
option as we have anywhere from 10-40 merges to trunk a week.  Mainly 
due to the fact that we push code live to our site twice a day from a 
staff of 20 developers.  And trunk in this case is our 'live' tree, 
basically, anything merged in there is on it's way to our production 
servers.

Anyone in a similar situation and figured out a better way to handle 
the merging issue? (I'd assume most subversion users actually work on a 
release cycle of more than 4 hours)

Thank you,
-David


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Questions about tag style branch/merge approach

[Travis P <sv...@castle.fastmail.fm>]

On May 4, 2004, at 12:27 PM, David Budworth wrote:

> We have been doing this as:
> svn del svn://repo/merge-points/mybranch -m 'resetting mp'
> svn cp svn://repo/trunk svn://repo/merge-points/mybranch

The del command will give you the revision number of the result.
Let it be 167 for this suggestion.
You could then:
   svn cp -r 167 svn://repo/trunk svn://repo/merge-points/mybranch

That is still not atomic, but it does eliminate the problem that you 
specifically cite:
> ... if someone commits to the trunk after I do my trunk merge and 
> before I re-create my merge point, I lose changes that the other 
> person committed to trunk.

Tagging an older revision is mentioned at the end of 'svn copy' page in 
the Subversion book.

-Travis


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Questions about tag style branch/merge approach

[Ben Collins-Sussman <su...@collab.net>]

On Tue, 2004-05-04 at 12:27, David Budworth wrote:

> Only problem is, how does one reset that merge point in an atomic 
> fashion?

> We have been doing this as:
> svn del svn://repo/merge-points/mybranch -m 'resetting mp'
> svn cp svn://repo/trunk svn://repo/merge-points/mybranch
> 

This is correct.

> 
> But it's not atomic, and if someone commits to the trunk after I do my 
> trunk merge and before I re-create my merge point, I lose changes that 
> the other person committed to trunk.

So stop copying the HEAD revision of trunk!  HEAD is a moving target, as
you say.  It could refer to r1213 one moment and r1214 the next.  If you
merge changes to a trunk WC and commit, note the exact revision number
you've created, say revision X.  Then run 'svn cp -rX trunkURL
mergepointURL'.


> Plus it revs to repo three times for every trunk merge cycle (not a big 
> deal, but mildly annoying)

Nothing you can do about that.  You don't have to delete old
mergepoints, of course.  You could just create a bunch of them: 
mergepointA, mergepointB, all the way through the alphabet.  Or give
them number prefixes.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org