[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: Wed, 09 Mar 2005 14:38:49 -0500
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Hash: SHA1

Frank Hemer wrote:

| On Wednesday 09 March 2005 15:50, Derek Price wrote:
|> Frank Hemer wrote: | Here is a more detailed description of the
|> tag-extensions:
|> Mostly this sounds great, with the few questions/exceptions that
|> I have noted.
|> Could you write the final version up as a patch to
|> doc/cvs.texinfo?
| I certainly will - but I was hoping to receive some reports about
| ev. bugs so these can be fixed _before_ the patch gets applied.
| Also you might have noted that I'm not a native english speaker, so
| this docu probably needs some workover ...

You won't be the first non-native english speaker to contribute to the
manual.  :)

|> | '.origin': Will always resolve to the very first revision. If a
|>  | file has been added on a branch, .origin will resolve to the
|> first | revision on that branch, otherwise it will follow the
|> mainline. | | '.root': Will resolv to  the predecessor of the
|> first revision on | the focused branch.
|> I think your terminology is still a little off here.
|> Technically, the root revision of a branch is on both the parent
|> and the branch and is therefore also the "first" revision on the
|> branch.  This is one of the reasons that I still think your
|> ".origin" tag makes no sense.  Could you please either remove it
|> or provide me with a use case that explains/justifies it?
| Ok, in this case 'first'  has to be replaced with 'second' for
| '.root'. But I suspect there is a better word for this?

How about "first"?  .root should resolve to the first revision on the
branch, the revision which is shared with its parent.  "The
predecessor of the second revision" is at least overly verbose and
will, at times, not make sense, since CVS does not require that a file
on a branch have a "second" revision in this sense.

| Regarding '.origin', it is the only way to target the very first
| version of a file. Using '.origin' and appending an individual
| number of '.next' extensions allows to iterate over all revisions
| of a file, begining at the initial version. The same purpose can be
| achieved with cvs log and taking the revision number - but I think
| '.origin' is much more handy here.

Ah, so you are saying that there is no way to iterate over the
revisions on a branch without a .origin tag.  BRANCH.root.next yields
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.

Also, iterating BRANCH via .prev until the result == BRANCH.root would
allow iteration in reverse without .origin, but this is not enough for
me to object to .origin any longer.

| If a file has been added on a branch, and consequently does not
| have a '.root' version (usually the dead 1.1), '.origin' will
| return the revision (if it has been called from this
| branch). After a merge onto the trunk, this behavior doesn't
| change. But if (then) invoked from the trunk, '.origin' will return
| 1.2 (or a higher rev. number, depending on the rev. num. it was
| committed to).
| If a file has been introduced by cvs import, '.origin' called from
| the trunk resolves to

Even after addition of rev. 1.2?  What about the case where newfile is
added to the trunk after other files were imported?  .origin would
return for some files and 1.1 for newfile.  A dead 1.1
revision for all newly created files would be required to make this

If this (dead 1.1 revisions) were implemented, then the warning I
mentioned above would not be necessry for .origin calculated against
the trunk.

|> | '.next': The next revision on the focused branch. Does _not_
|> follow | the mainline as this would prevent access to revisions
|> on a vendor | branch that were introduced _after_ the first
|> commit/merge onto the | trunk.
|> Could you please explain this in more detail?
| Assuming a file has been introduced with cvs import, it will start
| as 1.1 and The next vendor import creates and a
| third At this stage, the file becomes modified and
| committed to 1.2. Now two more vendor imports happen, creating
| and
| Starting from and applying several '.next' extensions
| allows to iterate over the vendor branch _without_ jumping onto the
| trunk. Because of this, will resolve to
| If it would follow the mainline, this would resolve to
| 1.2. Non-vendor branchens however are not affected by this.
| I'm not really sure whether this makes sense in all situations, but
| to work around this, '.next' would have to take the absolute tag
| type into account, blowing the code and maybe causing some
| sideeffects I haven't thought of yet. The code for simply always
| following the mainline is still in my private rep., maybe this
| functionality can be added in a later step?

I still don't understand what you are asking here.  Of course, .next
applied to any revision spec with an odd number of dots, e.g. 1.2,, or, should simply increment the last set of
digits (in the given example, to 1.3,, or until
it finds a revision that exists or determines that no further
revisions exist on the given branch (in the special case of the trunk,
this might mean checking 2.x, 3.x, etc as well, but this should
already be encoded somewhere in rcs.c).

How is this different from you .next specification or any other
"mainline" traversal?

|> | If a combined tag with relative extensions is used for commands
|>  | that change the local sandbox and set sticky tags, the
|> resulting | numeric revision is used for sticky tagging. This is
|> because tags | like .trunk.prev.prev imho don't really make sense
|> - '.prev', | '.next' will force usage of numeric sticky tags in
|> any position, | and all elative tags will if used not in head
|> position.
|> I agree with you here when .prev or .next are applied to a
|> dynamic (branch) tag, since a request like "the tipe of the
|> branch minus two revisions" seems unlikely to remain meaningful
|> in a dynamic sense, but I think that applied to a static tag it
|> would be best to leave the text in the sticky tag for
|> readibility.  "release-1.0.prev" is not going to change unless
|> someone moves the release-1.0 tag.
| Unfortunately I don't see an easy way to achieve this. How could I
| determine whether some tag is static or not? In vers_ts.c, I only
| have information about a symbolic tag, but I don't know if this is
| a branch tag or a static tag. I could resolve the tag (requiring
| rcs-file access) and make the numeric display dependent on the
| result but I think this points into the wrong direction. Is there
| an easy way to find out (in vers_ts.c) what kind of tag has been
| used before?

In the case where the information came out of the directory CVS/Tag
file, it becomes available in vers->nonbranch, but not otherwise.

In other cases, the RCS file gets parsed anyhow, but only on the
server.  Of course, since you need RCS information to resolve these
tags anyhow, I expect you are currently only doing so on the server
anyhow, whether you realized it or not.

Regardless, I am reconsidering the decision to store numerical
revision numbers for static tags.  Technically, HEAD is really a
static tag (it points to a particular set of revision numbers).  It
just happens to point to the most recent set on the trunk.  Therefore,
an update might retrieve a new head revision, but a commit will fail,
as things stand previous to your patch.  I've been assuming that .head
would work similarly.  Why not .prev and .next too?  Even if only to
simplify code, why not just leave the sticky tag just as the user
specified it?  It certainly fulfils the principle of least
interference, where the user is allowed to shoot themselves in the
foot if they like since they might find some use for a dynamic sticky
someday that we didn't imagine.

Of course, on the other side of this argument, I am fairly confident
that there should not be much use for such a dynamic sticky and,
therefore, storing a revision number when BRANCH.prev... is supplied,
should follow the principle of least suprise, even if it might make
status, log, etc. output slightly less legible.

What do others think?

|> | If the combined tag ends with '.head', this will overwrite -
|> Could you explain this further?
| Taking a rev. num. Using a tag like '.root.root.' will
| resolve to the numeric tag 1.3. Adding '.head' will resolve to the
| head of the trunk because '.head' turns the tag into a dynamic tag.
| In this case a numeric tag would simply be erroneus.

This is fine and exactly as I would have expected.

| Probably the difference between dynamic tags and relative tags
| should be mentioned: '.prev', '.next', '.root', '.origin' '.head'
| and '.base' are relative tags.
| Symbolic _branch_ tags and '.head' are dynamic tags.

Do you mean .trunk is dynamic here?  See my discussion of HEAD & .head

|> | I hope I have addressed all issues concerning the new tags, and
|>  | would very much appreciate some feedback and maybe some
|> results | from testing ...:-)
|> This all still sounds great, but it cannot be committed without
|> docs and test cases.
| I know, but I still I would like to get some feedback so I can
| provide a patch and use-cases that fullfill other users requiremens
| without having to work things over and over again. Actually, I was
| hoping some users apply the patch and play around a little ...

Well, I've thought of a few more interesting use/test cases for you:

~   1. Create a branch.  Add and commit newfile to trunk.  Add and
~      commit newfile to branch.

~      In this case, branch.root of newfile should point to a dead
~      revision, but I don't think it will.  To support this properly,
~      all newly created files will need a dead 1.1 revision for
~      branching cases like this.
~   2. Branch a project with several files.  commit some changes to a
~      subset of those files, on the branch.  branch the branch again.
~      repeat on the branch.

~      Now, file1.root.head from the branch of the branch could yield
~      the head of the first branch, while file2.root.head could yield
~      the head of the trunk.  This could probably be okay, but a test
~      case and a note in the docs warning users to expect this
~      behavior are probably in order.


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]