On Fri, 2004-07-23 at 15:17, Duncan Murdoch wrote:
> Turns out that pretty frequently we do merges for only a few files, or
> for a subtree, and sometimes do backports to the stable branch. So we
> can't just save the revision of the last merge in a file, we need a
> more complicated scheme, more closely equivalent to a CVS tag.
Ah, so your team *is* normal, then. :-)
I don't think any amount of scripting and automation is going to help,
then. Or rather, the complexity will become so immense, it's just
easier to port stuff as needed by hand.
You need to get out of the mindset of 'merging particular files' and
think about porting 'changesets' back and forth. You need to do what
the rest of us do: merge specific changesets by naming them via global
revnums. The book talks all about it, as you already know. It's much
easier to have a human being do this stuff, rather than creating
zillions of temporary tags.
Let me phrase it another way: the reason your current CVS process is so
obsessed with tag creation is because CVS has no ability to name/capture
changesets. Incessant tagging is the *only* way to approximate that
sort of thing: "let's see, to port this bugfix, I need to tag the tree
before committing, and tag it after committing, and then use those tags
to merge the change to a different branch."
In Subversion, the tagging isn't necessary. You just "port change r3981
from branchA to branchB". All the correct files are part of the
changeset already.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 23 22:25:43 2004