-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
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?
|> | 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.
Ok.
| 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.
Huh?
|> |> | 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 ...
...so the branch type *is* available where you wanted it, then...
|> | 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:-(
Ok.
|> |> | 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 ...
Yes. It just makes .root not necessarily work across multiple files, which is really my only motivation for wanting it in the first place. :(
|> ~ 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 ...
Thanks.
Regards,
Derek -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCL2d8LD1OTBfyMaQRAr1NAJ4sTOl7UZ7yc1MCeur69k8ZqHvH+ACgldIj XRrf8up1BJmRH3w2NjOwOJA= =ppe2 -----END PGP SIGNATURE-----
_______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
