> | I agree. I would really like a way to replace the idioms > | > | cvs tag foo-bp cvs tag -b foo-branch cvs up -r foo-branch .....lots > | of changes and commits.... cvs diff -rfoo-bp -rfoo-branch > | > | with something like: > | > | cvs tag -b foo-branch cvs up -r foo-branch .....lots of changes and > | commits.... cvs diff -rfoo-branch.root -rfoo-branch > | > | so that we don't need lots of foo-bp tags in the tree. > | > | The possibility of doing something like this: > | > | cvs tag -b -rfoo-branch.root foo-redeux-branch > | > | to allow the creation of an alternative implementation of modified > | code based on the same original baseline version as foo-branch > | would also be interesting. > > Neither of the two solutions I'm about to suggest would allow the > ".root" tag to work on on branches created by servers from before the > feature was installed, but I have thought of two alternative > implementations, one of which I have alredy suggested: > > ~ 1. Always add a "dead" 1.1 revision for new files, on the trunk or > ~ on a branch. Use this as the base for files added on a branch, > ~ even when they already exist on the trunk. This may have the > ~ advantage of solving some other issues. I found at least one > ~ thread discussing other reasons this might be desirable: > > <http://groups-beta.google.com/group/gnu.cvs.bug/browse_thread/thread/33273 >8c2632c2b26/ced1e465b0c1878d?q=bug-cvs+dead+1.1+revision+always#ced1e465b0c1 >878d>. > > ~ 2. Always add an actual "BRANCH.root" tag in the RCS archive when a > ~ tag is created. These could be suppressed in log output unless > ~ requested to avoid clutter. Look up this tag when ".root" tags > ~ are requested. This would be easier to implement, I think, but > ~ would not solve the other issues mentioned above and would > ~ prohibit constructs like "BRANCH.root.root". > > |> And there is the similar matter of `cvs diff -r.commitid.XXX.prev > |> -r.commitid.XXX'. I thought this sort of request was what got > |> you started on this? > | > | Yes, it would be highly desirable to be able to do > | > | cvs udpate -j.commitid.XXX -j.commitid.XXX.prev > | > | to reverse a particular patch.
Hold on ... it seems I have found a workaround for this: /* If a file was added on the trunk, and it is added on * a branch in a second step, the '1.1.2.1' revision is * dead, and timestamp of 1.1 and 1.1.2.1 are equal. * Prevent returning this as root! */ The revision numbers do not necessarily have to be those in the above example:-) Btw. the problem of .commitid.next and alike is already solved ... Regards Frank -- - The LinCVS Team - http://www.lincvs.com _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs