[Top][All Lists]

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

Re: Feature request/ideas

From: Derek Price
Subject: Re: Feature request/ideas
Date: Thu, 10 Mar 2005 10:25:02 -0500
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Hash: SHA1

Mark D. Baushke wrote:

| Derek Price <address@hidden> writes:
|> Frank Hemer wrote:
|> |> a revision on BRANCH's parent.  This makes sense when speaking
|>  |> about individual files, but use of .origin with multiple
|> files |> probably deserves some sort of warning to the user that
|> what they |> asked for may not make sense. | | | Well, as stated
|> before: All relative tags are _only_ valid for | individual
|> files, not for directories. It doesn't matter where the |
|> relative tag appears in a combined tag. | | If applied on a
|> directory, a warning will be shown complaining | about an invalid
|> tag. And cvs aborts.
|> Hrm.  The real strength of the .root tag, at least, is that it
|> makes `cvs diff -rBRANCH.root -rBRANCH' possible.  I would hate
|> to go to all this trouble and not get this feature.  It's just
|> plain not very useful otherwise.  The same tag specs could be
|> useful in a merge.
| 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:


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


Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


reply via email to

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