[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Feature request/ideas
From: |
Frank Hemer |
Subject: |
Re: Feature request/ideas |
Date: |
Thu, 10 Mar 2005 16:53:15 +0100 |
User-agent: |
KMail/1.5.1 |
> | 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
- Re: Feature request/ideas, (continued)
- Re: Feature request/ideas, Frank Hemer, 2005/03/08
- Re: Feature request/ideas, Derek Price, 2005/03/09
- Re: Feature request/ideas, Frank Hemer, 2005/03/09
- Re: Feature request/ideas, Derek Price, 2005/03/09
- Re: Feature request/ideas, Mark D. Baushke, 2005/03/09
- Re: Feature request/ideas, Derek Price, 2005/03/10
- Re: Feature request/ideas,
Frank Hemer <=
- Re: Feature request/ideas, Derek Price, 2005/03/10
- Re: Feature request/ideas, Frank Hemer, 2005/03/10
- Re: Feature request/ideas, Derek Price, 2005/03/11
- Re: Feature request/ideas - final patch, Frank Hemer, 2005/03/17
- Re: Feature request/ideas - final patch, Derek Price, 2005/03/19
- Re: Feature request/ideas - final patch, Derek Price, 2005/03/20