[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Maintaining branches...

From: Derek R. Price
Subject: Re: Maintaining branches...
Date: Thu, 14 Jun 2001 15:26:31 -0400

Mike Castle wrote:

> On Thu, Jun 14, 2001 at 12:57:30PM -0400, Greg A. Woods wrote:
> > That's the trick.  How do you do that without impacting RCS compatability???
> > Is doing it as part of the commit message sufficient?
> This can already be accomplished with external scripts that make use of
> magic values in commit messages.
> And even this, it only handles very special cases of merges.  That is, were
> all changes on one branch are merged into another.

Why?  There are other technical/usablity problems with this (maybe a nitpick
since much of this data could still be made useful, but I think it would be hard
to make CVS aware that a user had deleted the merged data from a file manually),
but I don't see any reason why both tags couldn't be stored for any merge.

Well, tags could be stored, but that would be useless...  individual file names
and revisions describing each diff would be necessary since tags can be moved.

Assigning change set names (perhaps only a timestamp though user, host, and
workspace might be useful information in the logs) would be useful as well,
I think.

> And I think that this complete merging happens less than you might think.
> It cannot handle the situation where a specific set of changes is migrated
> before another (i.e., -j tag1 -j tag2).  It may not even be off of an
> immediate branch, but rather a couple over.

What can't it handle about this and why?


Derek Price                      CVS Solutions Architect ( )
mailto:address@hidden         CollabNet ( )
Photons have mass?  I didn't know they were catholic!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]