Re: Feature request/ideas

[Frank Hemer]

> | 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