Re: Feature request/ideas

[Frank Hemer]

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

Absolutely. With the 'shared with parent' addon its strait forward:-)

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

Yes, got it.

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

> | 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 1.1.2.1 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 1.1.1.1.
>
> 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 1.1.1.1 for some files and 1.1 for newfile.  A dead 1.1
> revision for all newly created files would be required to make this
> meaningful.

As mentioned above, relative tags are not ...
So this only needs to be considered if invoked on more than one file at a 
time. Imho this is explicitely the users choice, and doesn't require an 
additional warning -

> 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 1.1.1.1. The next vendor import creates 1.1.1.2 and a
> | third 1.1.1.3 At this stage, the file becomes modified and
> | committed to 1.2. Now two more vendor imports happen, creating
> | 1.1.1.4 and 1.1.1.5.
> |
> | Starting from 1.1.1.1 and applying several '.next' extensions
> | allows to iterate over the vendor branch _without_ jumping onto the
> | trunk. Because of this, 1.1.1.1.next.next.next will resolve to
> | 1.1.1.4. 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,
> 1.1.1.1, or 1.137.14.980, should simply increment the last set of
> digits (in the given example, to 1.3, 1.1.1.2, or 1.137.14.981) 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?

The mainline traversal would behave as a reverse '.prev'. I have mentioned 
this different behavior because I expect an innocent user to think of '.prev' 
and '.next' as being the opposite.

A 'nice to have' would be following idea:
IMPORT_VENDOR_BRANCH.origin and several '.next' extensions follow the vendor 
branch while '.trunk.origin' and several '.next' extensions follow the 
mainline.

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

That were my assumptions ...

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

Yes, it was my intention that '.trunk' can be used exactly in the way a 
symbolic branch tag can be used. But I wouldn't compare it to your 
description of Head/.head. However the patch currently fails for a commit on 
a '.trunk' tagged revision. I'll have to fix that one:-(

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

You're right. However this is not an error in the patch but would have to be 
fixed in rcs itself. In the mentioned situation it resolves to 1.1 and thats 
exactly what '.root' should do ...

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

I'll add this ...

Regards
Frank
-- 
- The LinCVS Team -
http://www.lincvs.com