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
Received on Tue May 4 19:28:48 2004