Exactly. You still wouldn't have automagic access to back out ANY
merge, but you would if you limit yourself to one merge per branch and
avoid merging to anything but a branch's parent branch.
I guess if CVS remembered that you had just merged into your workspace
and asked "Are you committing merge X (-j branchY.tail -j
branchZ.head)?" or some such upon commit, the correct tagging could be
accomplished almost automagically.
Or, maybe, 'cvs ci -t' (t for tag, I don't have a better mnemonic at the
moment), always saves the tag upon commit? Hmm, the more I think about
this, the more I think I'd be tempted to make "automergetagging" the
default behavior.
The long way (but I think the way with the least side effects) to
accomplish this would be to save the revision numbers of both endpoints
of the merge for each affected (not changed, I think, though tagging
only changed files should provide the basic functionality I am
describing) file somewhere in the metadata upon merging and then tag the
start and end points properly upon commit.
The quick hack, I think, would be to tag the merge start with
"tobranch_merge_N_start_prelim" and create an equivalent "end" tag
(perhaps only if the appropriate revisions were untagged already) upon a
merge and then patch 'cvs release' to delete the preliminary tags if
they haven't been committed.
Of course, even quicker would simply be to have CVS tag everything
appropriate whenever it sees a '-j' and not even worry whether anything
had been committed. Assuming that the majority of merges did get
committed, this wouldn't be too messy, but you wouldn't be able to
reconstruct for SURE (well, you know :) that such and such a change had
been merged & committed. At least, not using the data trail.
'cvs history' could probably then be hacked to provide a list of merges,
probably with a branchname filter.
Anybody tempted to rip my designs to shreds yet?
Always grateful for the input. :)
Oh, and I'm not trying to contradict what a few of us have now said
about the magic branch functions. These two features should be
compatible.
Derek R. Price
CVS Solutions Architect
303.554.8291
[EMAIL PROTECTED]
http://alumni.engin.umich.edu/~oberon/resume.html
--
I thought I made a mistake once, but I was wrong.
Stephen Rasku wrote:
> Derek R. Price wrote:
>
> >Rather than a bunch of new magic tags, excepting perhaps '.trunk',
> allow
> >magic functions such as, '.parent', '.tail', and '.head' to be
> appended to
[snip]
> I like this solution. I don't like the fact that you currently have
> to tag a branch twice if you ever want to back it out. With this
> mechanism, all you would have to do is:
>
> cvs update -j branch -j branch.tail
>
> --
> Stephen Rasku E-mail: [EMAIL PROTECTED]
> Senior Software Engineer Phone: (604) 872-6676
> TGI Technologies Web: http://www.tgivan.com/
