Re: Feature request/ideas - final patch
Yes. It is ok to send intermediate patches.
Ok, here's the next. See src/ChangeLog for details -
Index: src/ChangeLog
===
RCS file: /cvs/ccvs/src/ChangeLog,v
retrieving revision 1.3165.2.5
diff -u -r1.3165.2.5 ChangeLog
--- src/ChangeLog 6 Apr 2005 20:11:52 - 1.3165.2.5
+++ src/ChangeLog 8 Apr 2005 17:56:15 -
@@ -1,3 +1,23 @@
+ * admin.c (admin_fileproc): Undo last commit. TAG_TRUNK test removed.
+ * commit.c (check_fileproc): Imporve comments. TAG_TRUNK test removed.
+ (commit_fileproc): TAG_TRUNK test removed.
+ (remove_file): TAG_TRUNK test removed.
+ * update.c (update_fileproc): TAG_TRUNK test removed.
+ * rcs.c: Improve comments.
+ (RCS_gethead): Remove this fn.
+ (RCS_getversion): TAG_TRUNK test removed.
+ (RCS_gettag): Remove magic conversion.
+ (RCS_nodeisbranch): Properly detect magic for numeric rev.
+ Remove magic conversion.
+ (RCS_whatbranch): Gratious reformatting. Simplify.
+ (translate_tag): Always return non-magic branches for symbolic/extended
+ tags. Add param flag to prevent conversion for non-extended tags.
+ Improve assumption verification.
+ (RCS_extract_tag): Adapt error msg to cvs conventions.
+ (RCS_getprevious): Rootdate comparison fixed.
+ (RCS_getroot): Remove magic conversion.
+ * sanity.sh: More tests added.
+
2005-04-06 Derek Price [EMAIL PROTECTED]
* rcs.c (RCS_getprevious): Remove erroneous FIXME.
Index: src/admin.c
===
RCS file: /cvs/ccvs/src/admin.c,v
retrieving revision 1.107.2.3
diff -u -r1.107.2.3 admin.c
--- src/admin.c 20 Mar 2005 23:41:36 - 1.107.2.3
+++ src/admin.c 8 Apr 2005 17:56:15 -
@@ -659,9 +659,13 @@
char *branch = admin_data-branch[2];
if (*branch != '\0' !isdigit ((unsigned char) *branch))
{
- error (0, 0, %s: Symbolic name %s is undefined.,
- rcs-path, admin_data-branch + 2);
- status = 1;
+ branch = RCS_whatbranch (rcs, admin_data-branch + 2);
+ if (branch == NULL)
+ {
+ error (0, 0, %s: Symbolic name %s is undefined.,
+ rcs-path, admin_data-branch + 2);
+ status = 1;
+ }
}
if (status == 0)
RCS_setbranch (rcs, branch);
Index: src/commit.c
===
RCS file: /cvs/ccvs/src/commit.c,v
retrieving revision 1.252.2.1
diff -u -r1.252.2.1 commit.c
--- src/commit.c19 Mar 2005 15:32:14 - 1.252.2.1
+++ src/commit.c8 Apr 2005 17:56:15 -
@@ -700,6 +700,8 @@
Lock_Cleanup ();
dellist (mulist);
+/* add the commitid to val-tags
+ */
char *commitid = Xasprintf (@%s, global_session_id);
tag_check_valid (commitid, argc, argv, local, aflag, , true);
free (commitid);
@@ -890,16 +892,13 @@
finfo-fullname);
goto out;
}
- if (status == T_MODIFIED vers-tag)
+ if (status == T_MODIFIED vers-tag
+ !RCS_isbranch (finfo-rcs, vers-tag))
{
- if ( (*(vers-tag) != '.' || strcmp (vers-tag+1, TAG_TRUNK))
- !RCS_isbranch (finfo-rcs, vers-tag) )
- {
- error (0, 0,
- sticky tag `%s' for file `%s' is not a branch,
- vers-tag, finfo-fullname);
- goto out;
- }
+ error (0, 0,
+ sticky tag `%s' for file `%s' is not a branch,
+ vers-tag, finfo-fullname);
+ goto out;
}
}
if (status == T_MODIFIED !force_ci vers-ts_conflict)
@@ -1362,7 +1361,6 @@
{
char *rev = RCS_getversion (finfo-rcs, write_dirtag, NULL, 1, NULL);
if (rev != NULL
-!(*write_dirtag == '.' !strcmp (write_dirtag+1, TAG_TRUNK))
!RCS_nodeisbranch (finfo-rcs, write_dirtag))
write_dirnonbranch = 1;
if (rev != NULL)
@@ -1420,16 +1418,6 @@
}
else if (ci-status == T_ADDED)
{
-
-/* prevent adding files to a branch named TAG_TRUNK as this
-* is a synonym for the trunk itself
-*/
-if (ci-tag *ci-tag == '.' !strcmp (ci-tag + 1, TAG_TRUNK))
- {
- free (ci-tag);
- ci-tag = NULL;
- }
-
if (checkaddfile (finfo-file, finfo-repository, ci-tag, ci-options,
finfo-rcs) != 0)
{
@@ -1448,7 +1436,7 @@
/* If numeric, it is on the trunk; check_fileproc enforced
this. */
!isdigit ((unsigned char) ci-tag[0]))
- {
+
Re: Feature request/ideas - final patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | I have adapted most of the broken code, so again all tests pass. | Unfortunately RCS_tag2rev() needs a special handling because it is | responsible for adding rev. numbers (with magic) to the RCS file. I | also had to fix part of the old code because for ex. | RCS_nodeisbranch didn't properly detect a branch with plain | revision numbers which lead to many workarounds. Your fix of | admin.c broke parts of the existing code that wasn't tested by | sanity.sh (symbolic tags with admin -b), this is fixed too. I | started to add some more tests but still this is not sufficiant. I | think it might make sense to put an intermediate commit to the | newtags branch to make development less complex. Is it ok to send | intermediate patches (tests pass but more work to be done)? Yes. It is ok to send intermediate patches. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVUAhLD1OTBfyMaQRArURAJ9P7T1s6l632K6FeVPZY/wUtLYzkgCglBaM nCo/dLct6sErMnstkpb1WV4= =AScR -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas - final patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | Frank, | | I've committed a few new changes and the tests are passing again, | including your new tag-ext tests. | | I also added a FIXME comment or two. Please take a look, | especially at the one in RCS_getprevious. | | | Well, according to my comment above your FIXME (RCS_getprevious) | the code does exactly what your fixme suggests;-) Yep. Sorry. I've removed the FIXME. | I've spotted several errors and omissions so far and have cause | to wonder if the only reason tag-ext passes currently is that | testing is not complete. Please see what you can do about adding | more tests. | | | Could you provide more details what exactly fails? Regarding your | changes several assumptions are broken. Did you test with my | original patch? I tested with your original patch. It passed the tests you provided. I still thought your code was overly complicated. For one thing, you had a bunch of special casing for the .trunk case which I thought was unnecessary. I started removing some of it from one file, admin.c. One of the basic changes that made this possible was simply returning a branch number (like 1, or 2) for the trunk, or maybe it was the head revision of the trunk, from RCS_gettag, and returning the latest revision on the trunk from RCS_tag2rev. I also started removing some obfuscations in the RCS_* and some other functions in rcs.c, including several of your new functions, like translate_tag. I also added assertions that some of the assumptions you missed were true, for reference, as I simplified the functions based on these assumptions. I managed to verify that the old and new tests referencing the admin command still pass, but some of my changes to the rcs.c functions have broken your new code for other CVS commands that are probably still special casing and/or depend on the old behavior of the new functions. Please take a look at the diffs and the new comments and assertions now on the newtags branch in the CVS repository and see if you can complete the revisons I started to your patch. Also, your work needs more complete comments for final acceptance accepted. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVEDPLD1OTBfyMaQRAhTdAKCP9Wu9ExIeih/clzfCyfapGYCpMQCgyOCV gDskum3jG2igw4w/w7KRJVA= =Ni/P -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas - final patch
| I've spotted several errors and omissions so far and have cause | to wonder if the only reason tag-ext passes currently is that | testing is not complete. Please see what you can do about adding | more tests. | | Could you provide more details what exactly fails? Regarding your | changes several assumptions are broken. Did you test with my | original patch? I tested with your original patch. It passed the tests you provided. I still thought your code was overly complicated. For one thing, you had a bunch of special casing for the .trunk case which I thought was unnecessary. I started removing some of it from one file, admin.c. One of the basic changes that made this possible was simply returning a branch number (like 1, or 2) for the trunk, or maybe it was the head revision of the trunk, from RCS_gettag, and returning the latest revision on the trunk from RCS_tag2rev. I also started removing some obfuscations in the RCS_* and some other functions in rcs.c, including several of your new functions, like translate_tag. I also added assertions that some of the assumptions you missed were true, for reference, as I simplified the functions based on these assumptions. I managed to verify that the old and new tests referencing the admin command still pass, but some of my changes to the rcs.c functions have broken your new code for other CVS commands that are probably still special casing and/or depend on the old behavior of the new functions. Please take a look at the diffs and the new comments and assertions now on the newtags branch in the CVS repository and see if you can complete the revisons I started to your patch. Also, your work needs more complete comments for final acceptance accepted. I have adapted most of the broken code, so again all tests pass. Unfortunately RCS_tag2rev() needs a special handling because it is responsible for adding rev. numbers (with magic) to the RCS file. I also had to fix part of the old code because for ex. RCS_nodeisbranch didn't properly detect a branch with plain revision numbers which lead to many workarounds. Your fix of admin.c broke parts of the existing code that wasn't tested by sanity.sh (symbolic tags with admin -b), this is fixed too. I started to add some more tests but still this is not sufficiant. I think it might make sense to put an intermediate commit to the newtags branch to make development less complex. Is it ok to send intermediate patches (tests pass but more work to be done)? Regards Frank ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas - final patch
Frank, I've committed a few new changes and the tests are passing again, including your new tag-ext tests. I also added a FIXME comment or two. Please take a look, especially at the one in RCS_getprevious. Well, according to my comment above your FIXME (RCS_getprevious) the code does exactly what your fixme suggests;-) I've spotted several errors and omissions so far and have cause to wonder if the only reason tag-ext passes currently is that testing is not complete. Please see what you can do about adding more tests. Could you provide more details what exactly fails? Regarding your changes several assumptions are broken. Did you test with my original patch? Regards Frank -- - The LinCVS Team - http://www.lincvs.com ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas - final patch
Derek Price wrote: Frank Hemer wrote: | I have finally finished my patch, tests and alike are contained: I've checked this in on the newtags branch in the main repository and started with some simplification and cleanup. If you are going to do any further work on this, please work and create patches from there to ease merging difficulties. Frank, I've committed a few new changes and the tests are passing again, including your new tag-ext tests. My take so far is that your code could be much cleaner and simpler with a little more work. It also needs a lot more comments. Please take a look at what I did to RCS_getprevious, RCS_getorigin, translate_tag as examples and see what you can do. Also, please remove the special casing for .trunk in all files and functions but src/rcs.c (translate_tag), as I did for admin.c. It should not be necessary. I also added a FIXME comment or two. Please take a look, especially at the one in RCS_getprevious. I've spotted several errors and omissions so far and have cause to wonder if the only reason tag-ext passes currently is that testing is not complete. Please see what you can do about adding more tests. Regards, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas - final patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | I have finally finished my patch, tests and alike are contained: I've checked this in on the newtags branch in the main repository and started with some simplification and cleanup. If you are going to do any further work on this, please work and create patches from there to ease merging difficulties. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCPGXfLD1OTBfyMaQRAlofAKD2LNaPHptNe5Vtb/nB72V4BTDevQCeOG0n hzLSX4tB0+kUccMjrRTohCE= =4yuN -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | Also, .commitid.next as currently defined should be nonsense in | almost all cases. Only .commitid .commitid.prev are | meaningful. | | | Thats right. However it would require extra code to prevent this, | and I don't really think this will cause problems. I assume a user | who is willing to type such a number probably knows what he's | doing?;-) I agree. I didn't mean to suggest prohibiting it. | As an extension to my doc: If no files are specified (recursive | calls or calls on a flat dir), all combined tags need to be | absolute. '.base.next' is invalid here, because it depends on the | specific file's rev number and subconsequently cannot serve as a | dirtag (on commands like update ...). '.trunk.prev' would be ok | here. So if applied on directories, a tag needs to start with | either a numeric rev. num, '.trunk', '.commitid' or a symbolic tag. | .base should apply recursively from a workspace. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMbrALD1OTBfyMaQRAjQ2AJ9hzfbaR2YnOvPfHUVDZIWxk8RkaACg8VAg tMb5A7y3V1GUrZObtyW13jY= =dyAq -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: | Derek Price [EMAIL PROTECTED] 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: http://groups-beta.google.com/group/gnu.cvs.bug/browse_thread/thread/332738c2632c2b26/ced1e465b0c1878d?q=bug-cvs+dead+1.1+revision+always#ced1e465b0c1878d. ~ 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. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMGbOLD1OTBfyMaQRAts8AJ4zWxmqruyxSYHwgS7DJHzQYikLYwCcCZyD VcZThzhvdjp9iUqsdDL1J0o= =+Y7L -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
| 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 ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | 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! */ Hrm. Yes, I think you have it, in about as backwards compatible a manner as possible (this will cause .root to work consistently for any branch if a is file added to a branch with a server with this change). It won't retroactively fix old branches to work with .root, but that's not possible to automate since the information just plain isn't available in the archive files. The only other potential insertion that might work that I can think of, would be to try and insert a dead 1.0 revision for all files and branch off that, but that would require more research to see how many assumptions were violated in the CVS source. Of course, I can think of no additional advantages of this solution, even if it turned out to work, other than allowing a standard base revision for files added on branches, which I only see as useful to humans gleaning info by perusing status messages and logs. I see little reason to prefer it. So anyway, I think I would be happy with the solution you suggest, without further research. | 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 ... | I was simply wondering because you specified that .prev and .next could only be applied to one file at a time. Also, .commitid.next as currently defined should be nonsense in almost all cases. Only .commitid .commitid.prev are meaningful. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMJhELD1OTBfyMaQRAmpFAKD++XaS4keQ7upekWTn2maKCbbVwACgq6Qm Gh72BBzokpeMHbIhIKRdkcw= =48+D -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
On Thursday 10 March 2005 19:56, Derek Price wrote:
Frank Hemer wrote:
| 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! */
Hrm. Yes, I think you have it, in about as backwards compatible a
manner as possible (this will cause .root to work consistently for any
branch if a is file added to a branch with a server with this
change). It won't retroactively fix old branches to work with .root,
but that's not possible to automate since the information just plain
isn't available in the archive files.
The only other potential insertion that might work that I can think
of, would be to try and insert a dead 1.0 revision for all files and
branch off that, but that would require more research to see how many
assumptions were violated in the CVS source. Of course, I can think
of no additional advantages of this solution, even if it turned out to
work, other than allowing a standard base revision for files added
on branches, which I only see as useful to humans gleaning info by
perusing status messages and logs. I see little reason to prefer it.
Well, I think it would be a good idea to add the same behavoir (as adding
on an existing branch) to the import feature. If vendor importing on several
vendor branches (1.1.1, 1.1.2, 1.1.3), there is no dead revision introduced.
However I think this is sth. thats very rarely used -
So anyway, I think I would be happy with the solution you suggest,
without further research.
:-)
Patch follows
| 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 ...
I was simply wondering because you specified that .prev and .next
could only be applied to one file at a time.
That was a misunderstanding;-)
I had limited it to _several_ files, because initialy there were problems with
the dirtag. This is set before vers_ts.c comes into action, so I was trying to
prevent interference of the already changed dirtag when calculating the
absolute revisions.
However, I have changed this and hopefully this works now as expected.
The '.root' returns a dead revision when first added on a branch. And I tried
it with several variants of vendor tags at a time, still there are so many
different ways I will not be able to try them all ...
Also, .commitid.next as currently defined should be nonsense in almost
all cases. Only .commitid .commitid.prev are meaningful.
Thats right. However it would require extra code to prevent this, and I don't
really think this will cause problems. I assume a user who is willing to type
such a number probably knows what he's doing?;-)
As an extension to my doc:
If no files are specified (recursive calls or calls on a flat dir),
all combined tags need to be absolute. '.base.next' is invalid here, because
it depends on the specific file's rev number and subconsequently cannot
serve as a dirtag (on commands like update ...). '.trunk.prev' would be ok here.
So if applied on directories, a tag needs to start with either a numeric rev.
num,
'.trunk', '.commitid' or a symbolic tag.
Now the patch, I'll care for doc and stuff next week - no more time right now.
Still it would be good if someone else would try out my hack -
patch
Index: src/admin.c
===
RCS file: /home/frank/CVS_ROOT/ccvs/src/admin.c,v
retrieving revision 1.1.1.3
retrieving revision 1.2
diff -b -B -u -r1.1.1.3 -r1.2
--- src/admin.c 8 Mar 2005 01:18:17 - 1.1.1.3
+++ src/admin.c 8 Mar 2005 19:37:41 - 1.2
@@ -655,6 +655,10 @@
char *branch = admin_data-branch[2];
if (*branch != '\0' ! isdigit ((unsigned char) *branch))
{
+ if (*branch == '.' !strcmp (branch+1, TAG_TRUNK))
+ branch = NULL;
+ else
+ {
branch = RCS_whatbranch (rcs, admin_data-branch + 2);
if (branch == NULL)
{
@@ -663,6 +667,7 @@
status = 1;
}
}
+ }
if (status == 0)
RCS_setbranch (rcs, branch);
if (branch != NULL branch != admin_data-branch[2])
Index: src/commit.c
===
RCS file: /home/frank/CVS_ROOT/ccvs/src/commit.c,v
retrieving revision 1.1.1.4
retrieving revision 1.8
diff -b -B -u -r1.1.1.4 -r1.8
--- src/commit.c11 Mar 2005 02:22:47 - 1.1.1.4
+++ src/commit.c11 Mar 2005 02:24:16 - 1.8
@@ -700,6 +700,10 @@
Lock_Cleanup ();
dellist (mulist);
+char *commitid = Xasprintf (@%s, global_session_id);
+tag_check_valid (commitid, argc, argv, local, aflag, , true);
+free (commitid);
+
/* see if we need to sleep before returning to avoid
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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? | '.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? | '.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? | 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. | If the combined tag ends with '.head', this will overwrite - Could you explain this further? | 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. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCLw0zLD1OTBfyMaQRAlYnAJ46v9suhl9Y576IjI5GZGcWckHyBwCeNNtj cPhg1i6KXaiOwvz6PEgZIX8= =vEFi -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
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 ... | '.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? 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. 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. | '.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? | 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? | If the combined tag ends with '.head', this will overwrite - Could you explain this further? Taking a rev. num. 1.3.4.7.2.3. 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
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- 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 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. 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.
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: 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? Does -r.prev mean anything (is it another way to say -r.base.prev)? If so, there are some kinds of relative sticky tags that would need to be resolved in some way if they are to be made the sticky revision. I have no objections to a cvs checkout -rcvs1-11-x-branch-last-merge.prev ccvs and having the sticky revision in use be updated when the cvs1-11-x-branch-last-merge tag is moved. However, I am not sure I understand how 'cvs update -r.base.prev foo' could work as anything other than a 1.48.4.7.prev as the sticky version for a file where the baseline version for foo was 1.48.4.7. I am also wondering how the datestamp version can generally interact with the new .prev and .next tags... -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCL1es3x41pRYZE/gRAiw+AKCeiMkGxMU6v2jxylYTs3J3oPVoiQCgkPQE MqK3n39/wztXp4QK4Dp6gKw= =PQk4 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
| | '.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
Re: Feature request/ideas
On Wednesday 09 March 2005 21:08, Mark D. Baushke wrote: Derek Price [EMAIL PROTECTED] writes: 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? Does -r.prev mean anything (is it another way to say -r.base.prev)? Yes, exactly. If so, there are some kinds of relative sticky tags that would need to be resolved in some way if they are to be made the sticky revision. I have no objections to a cvs checkout -rcvs1-11-x-branch-last-merge.prev ccvs and having the sticky revision in use be updated when the cvs1-11-x-branch-last-merge tag is moved. which is basically a good idea ... However, I am not sure I understand how 'cvs update -r.base.prev foo' could work as anything other than a 1.48.4.7.prev as the sticky version for a file where the baseline version for foo was 1.48.4.7. And here you are. Because otherwise (after the update) you would have a sticky tag '.base.prev' and a revision number of 1.48.4.6. The next call to update (without any params) would again reduce the revision number by one - and that's not a good idea;-) To prevent this, my code in vers_ts.c would need to know whether the symbolic tag is a branch tag (a dynamic tag) or not, and the tag would only be reverted into a numeric tag in case it is a static tag. I am also wondering how the datestamp version can generally interact with the new .prev and .next tags... It can not, as it requires a dynamic tag. And there are only symbolic branch tags and '.trunk'. If a relative tag extension is used, the result is the same as if the datestamp version was used with a numeric revision: cvs diff: tag 1.3 is not in file foo Regards Frank -- - The LinCVS Team - http://www.lincvs.com ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-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
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] 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. 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. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCL2q63x41pRYZE/gRAmk9AJ4n+e6RZLChAp4cpIZXSO3SIkoNVgCfRyJs aiIYG3QNNVv1DN1QU7BllGc= =Wi+5 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
Here is a more detailed description of the tag-extensions:
Terminologie:
Following the mainline (backwards):
Starting from a specific rev. number X on the trunk or a branch, the line is
followed backwards up to the first revision Z on the trunk. It doesn't matter
if there are dead or missing revisions in between. If this first revision is
dead, and its the 1.1 rev., stop here.
If 1.1 is not dead, and 1.1 was created at the same time the first vendor
branch rev. was created, jump to the vendor branch, and take the latest
revision prior to the date of Y (Z is the predecessor of Y).
Otherwise take 1.1.
Absolute tag means a tag that specifies either a revision or a trunk/branch.
'.trunk', 'n.u.m.e.r.i.c' and symbolic tags are absolute tags.
Relative tag means a tag that specifies a revision relative to a certain
starting point.
'.prev', '.next', '.root', '.origin' '.head' and '.base' are relative tags.
The 'focused branch' is used as a synonym for either the trunk or the branch,
depending on the sticky tag of the addressed file or the workdir.
If a relative tag is in head position, the absolute position is calculated from:
1. The sandbox revision's tag
2. The sandbox revision's dir-tag
3. The sandbox revisions revision number
4. The mainline
in this order, whatever is first available.
Absolute tags and relative tags may be combined. If a relative tag follows an
absolute tag, the result will be absolute.
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.
'.trunk': Serves as a synonym for the trunk-branch. Resolves to the most recent
revision of the mainline, and allows to be used as a branch tag if combined
with a date ('xxx -r .trunk:2005-03-08 18:00:00).
'.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.
'.base': The current sandbox revision. May only be used in head position.
'.head': The most recent revision on the focused branch.
'.prev': The previous revision on the focused branch. Follows the mainline.
'.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.
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. If the combined tag ends with
'.head', this will overwrite -
I hope I have addressed all issues concerning the new tags,
and would very much appreciate some feedback and maybe
some results from testing ...:-)
the patch
Index: src/admin.c
===
RCS file: /home/frank/CVS_ROOT/ccvs/src/admin.c,v
retrieving revision 1.1.1.3
retrieving revision 1.2
diff -b -B -u -r1.1.1.3 -r1.2
--- src/admin.c 8 Mar 2005 01:18:17 - 1.1.1.3
+++ src/admin.c 8 Mar 2005 19:37:41 - 1.2
@@ -655,6 +655,10 @@
char *branch = admin_data-branch[2];
if (*branch != '\0' ! isdigit ((unsigned char) *branch))
{
+ if (*branch == '.' !strcmp (branch+1, TAG_TRUNK))
+ branch = NULL;
+ else
+ {
branch = RCS_whatbranch (rcs, admin_data-branch + 2);
if (branch == NULL)
{
@@ -663,6 +667,7 @@
status = 1;
}
}
+ }
if (status == 0)
RCS_setbranch (rcs, branch);
if (branch != NULL branch != admin_data-branch[2])
Index: src/commit.c
===
RCS file: /home/frank/CVS_ROOT/ccvs/src/commit.c,v
retrieving revision 1.1.1.2
retrieving revision 1.4
diff -b -B -u -r1.1.1.2 -r1.4
--- src/commit.c2 Mar 2005 01:36:28 - 1.1.1.2
+++ src/commit.c2 Mar 2005 01:40:09 - 1.4
@@ -698,6 +698,10 @@
Lock_Cleanup ();
dellist (mulist);
+char *commitid = Xasprintf (@%s, global_session_id);
+tag_check_valid (commitid, argc, argv, local, aflag, , true);
+free (commitid);
+
/* see if we need to sleep before returning to avoid time-stamp races */
if (
#ifdef SERVER_SUPPORT
@@ -884,8 +888,10 @@
finfo-fullname);
goto out;
}
- if (status == T_MODIFIED vers-tag
- !RCS_isbranch (finfo-rcs, vers-tag))
+ if (status == T_MODIFIED vers-tag)
+ {
+ if
Re: Feature request/ideas
On Saturday 05 March 2005 00:15, Derek Price wrote: Derek Price wrote: Mark D. Baushke wrote: | Therefore, I suppose that there could be a need for .origin to be | the first revision on TRUNK This would seldom mean much across multiple files, so I still think .origin should not be used. The case Frank cited, where he is basically trying to diff against an import (thought not generated using the import command), is the only one where all the .origin revisions will be related in a sensible way, and even then only if no files have been added or removed on the trunk. Once files have been added or removed, you degenerate to the case where the .origin revisions (or even 1.1 revisions) of these files could have been added at different times and offering to calculate .origin is misleading at best. The only consistent way to do this is to tag everything after the import and diff against that tag. This tag couldn't even really be automated, except in something like the import command, which imports a set of files at once and tags the set. .origin makes no sense. And furthermore, in the use case Frank mentioned, the commitid should now fulfill the need .origin was serving. As I stated before, there are certainly several ways to achieve this. But all of them require more interaction than typing a single expression. To compare against a commitid, you need to know the commitid, and it probably requires to run cvs log before. To tag an import or add requires doing it _always_. If a file is added on a branch, and its contents hasn't been hacked from scratch but taken from somewhere else, it might again become interesting what has been changed between add and the current head of the branch. Granted, usage of .origin would seldom mean much across multiple files, but still it has a specific meaning on single files, or a selection of files. All in all, I think the convenience of a single expression more than balances the chance of being misleading. However it might make sense to only allow .origin to be used at maximum on a selection of files, and prevent usage on directories with no filenames specified. A more detailed description of the current .origin behavior will follow with my next patch ... probably later today? Regards Frank -- - The LinCVS Team - http://www.lincvs.com ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
Derek Price wrote: Mark D. Baushke wrote: | Therefore, I suppose that there could be a need for .origin to be | the first revision on TRUNK This would seldom mean much across multiple files, so I still think .origin should not be used. The case Frank cited, where he is basically trying to diff against an import (thought not generated using the import command), is the only one where all the .origin revisions will be related in a sensible way, and even then only if no files have been added or removed on the trunk. Once files have been added or removed, you degenerate to the case where the .origin revisions (or even 1.1 revisions) of these files could have been added at different times and offering to calculate .origin is misleading at best. The only consistent way to do this is to tag everything after the import and diff against that tag. This tag couldn't even really be automated, except in something like the import command, which imports a set of files at once and tags the set. .origin makes no sense. And furthermore, in the use case Frank mentioned, the commitid should now fulfill the need .origin was serving. :) Regards, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
| A rational way. As a second step I would suggest to change the | extensions (.prev, .next, .xxx) to be allowed in head position too, | but I'm note sure where the sandbox tag gets processed. If | translate_tags() could take that into account, its not a big deal | ... Where is this state cached? It's cached in the CVS/Entries files in each subdir. CVS looks it up in the Version_TS in vers_ts.c and decides to set it in the Vers_TS structure it returns only if the TAG passed to the function (via -r or something, somewhere) is not set. I think it could be caught there - if the TAG is .XXX (and not .trunk), then set the vers_ts-tag to STICKY.XXX. Ok, thats the 'client' side. But where is it cached on the 'server' side? | So probably the expression used should connote this. After some | consideration, I would vote for '.origin' here. I disagree with | being meaningless. I often export a project state into a local | repository, work on it, and when I'm done, move the files back to | the remote repository's sandbox. During local development I often | want to compare to the initial version of a file, and using a | single tag for this is just easy. Granted there are other ways to | achieve this, but they're not as easy to handle. That's fine for 1.1, but how does this help you for a branch? You might want to diff against the root, but it doesn't make much sense to care about the first revision on the branch. Good point. What about resolving '.origin' to the very first revision of the mainline? Regards Frank ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
Derek Price wrote: | | So probably the expression used should connote this. After some | | consideration, I would vote for '.origin' here. I disagree | with | being meaningless. I often export a project state into a | local | repository, work on it, and when I'm done, move the files | back to | the remote repository's sandbox. During local | development I often | want to compare to the initial version of a | file, and using a | single tag for this is just easy. Granted | there are other ways to | achieve this, but they're not as easy | to handle. | | That's fine for 1.1, but how does this help you for a branch? | You might want to diff against the root, but it doesn't make much | sense to care about the first revision on the branch. | | | Good point. What about resolving '.origin' to the very first | revision of the mainline? I don't have any reason to object to that. On further consideration, why doesn't -r1.1 suffice for what you want to do? Regards, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: Derek Price wrote: | | So probably the expression used should connote this. After some | | consideration, I would vote for '.origin' here. I disagree | with | being meaningless. I often export a project state into a | local | repository, work on it, and when I'm done, move the files | back to | the remote repository's sandbox. During local | development I often | want to compare to the initial version of a | file, and using a | single tag for this is just easy. Granted | there are other ways to | achieve this, but they're not as easy | to handle. | | That's fine for 1.1, but how does this help you for a branch? | You might want to diff against the root, but it doesn't make much | sense to care about the first revision on the branch. | | | Good point. What about resolving '.origin' to the very first | revision of the mainline? I don't have any reason to object to that. On further consideration, why doesn't -r1.1 suffice for what you want to do? Possibly for handling the following conditions... - cvs add foo cvs commit -mnew foo echo newstuff foo \ cvs commit -mupdate foo cvs admin -o1.1 foo .origin == 1.2 after this operation - cvs add foo cvs commit -mnew -r2.1 foo .origin == 2.1 - cvs tag -b foo-branch cvs update -rfoo-branch cvs add foo \ cvs commit -mnew foo In this case, is .origin == 1.1 (dead) or is it not found? - cvs tag -b foo-branch cvs update -rfoo-branch cvs add foo \ cvs commit -mnew foo cvs update -A cvs up -jfoo-branch \ cvs commit -mmerge foo .origin == 1.2 I have no objections to .origin being used for the very first revision of the mainline. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJzbw3x41pRYZE/gRApiNAKC8hOUGy1lvebo27DDnxlXORclf3ACdHabl CAwLIZj9tAonI7HPZGzhEzM= =GtfW -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
Mark D. Baushke writes: I have no objections to .origin being used for the very first revision of the mainline. Why bother with a special name? Just use .trunk.root. -Larry Jones Ever notice how tense grown-ups get when they're recreating? -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones [EMAIL PROTECTED] writes: Mark D. Baushke writes: I have no objections to .origin being used for the very first revision of the mainline. Why bother with a special name? Just use .trunk.root. Hmmm... true enough. The .origin modifier is not needed. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJz7i3x41pRYZE/gRAhGOAKCTH43+MaleWMGCDnQnqaB8hkENogCeIlxy MZp0E7grYWDn84dUoMuPUK4= =Tizu -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: | Derek Price [EMAIL PROTECTED] writes: | | Derek Price wrote: | | | | So probably the expression used should connote this. After | some | | consideration, I would vote for '.origin' here. I | disagree | with | being meaningless. I often export a project | state into a | local | repository, work on it, and when I'm | done, move the files | back to | the remote repository's | sandbox. During local | development I often | want to compare | to the initial version of a | file, and using a | single tag | for this is just easy. Granted | there are other ways to | | achieve this, but they're not as easy | to handle. | | | That's fine for 1.1, but how does this help you for a branch? | | You might want to diff against the root, but it doesn't make | much | sense to care about the first revision on the branch. | | | | Good point. What about resolving '.origin' to the very | first | revision of the mainline? | | | I don't have any reason to object to that. | | | On further consideration, why doesn't -r1.1 suffice for what you | want to do? | | | Possibly for handling the following conditions... | | - cvs add foo cvs commit -mnew foo echo newstuff foo \ | cvs commit -mupdate foo cvs admin -o1.1 foo | | .origin == 1.2 after this operation | | - cvs add foo cvs commit -mnew -r2.1 foo | | .origin == 2.1 Well, yes, but -r1.2 or -r2.1 would suffice in these cases, though I will grant you have to know what revision to use. I would hazard that there is either a -rrev revision that can be specified here across multiple files or that the result of a multi-file .origin will likely be meaningless anyhow. In the specific example Frank specified, also, -r1.1 should always work. | - cvs tag -b foo-branch cvs update -rfoo-branch cvs add foo \ | cvs commit -mnew foo | | In this case, is .origin == 1.1 (dead) or is it not found? I have no idea. I think for most use cases either will have the same result. For cvs up -r.origin foo, where foo has no origin, I see little difference between an error message that says .origin not found and a silent checkout of nothing (the dead revision), but maybe someone else has a reason to prefer one over the other. | - cvs tag -b foo-branch cvs update -rfoo-branch cvs add foo \ | cvs commit -mnew foo cvs update -A cvs up -jfoo-branch \ | cvs commit -mmerge foo | | .origin == 1.2 I don't think so. This should be consistent with the answer to your previous question. If the -r.origin with only a dead revision returns the dead revision, then this .origin should also return it. If - -r.origin with only a dead revision returns no revision, then this should return 1.2, as you specify. | I have no objections to .origin being used for the very first | revision of the mainline. It's not that big a deal, really, but I would like to hear a use case that can't be satisified with a simple revision selection or hear a person or two declare strongly that they prefer the convenience of an .origin that may sometimes be meaningless to an additional call or two to `cvs log'. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJ0A8LD1OTBfyMaQRAsjPAKDAJODmsV7MYXc+LJ/eQ6wI9XDPmgCg257L Ntyx7xsNC6o6XAr15UT/Yrw= =UzxB -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: | Larry Jones [EMAIL PROTECTED] writes: | | Mark D. Baushke writes: | | I have no objections to .origin being used for the very first | revision of the mainline. | | Why bother with a special name? Just use .trunk.root. | | | Hmmm... true enough. The .origin modifier is not needed. I thought Mark was just saying earlier in this thread that .trunk.root, by virtue of .root normally specifying a revision on the parent branch, should refer to the `0' revision? Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJ0IOLD1OTBfyMaQRAj6rAJ9gZI9mNMCT5aukpgDjh/4u6i1VyQCgloFJ /R17eO0mATKq3GlWD8WcXw8= =rKbJ -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: I thought Mark was just saying earlier in this thread that .trunk.root, by virtue of .root normally specifying a revision on the parent branch, should refer to the `0' revision? Hmmm... I may be getting confused, I thought .trunk.root.prev would be the `0' revision, but if you are right then .trunk.root.next would be the same as .origin right? As for `0', we probably need to be more consistent about it... for example, the command: cvs rdiff -r0 -r1.1 foo-module/foo-file yeilds a diff against /dev/null of the foo-file while the commands cvs co foo-module cd foo-module cvs diff -r0 -r1.1 foo-file yeilds an error message: 'cvs diff: tag 0 is not in file foo-file' this probably needs to be `fixed' to do something reasonable with `0' for most uses as a phantom revision that exists before the file existed on the branch or trunk. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJ0QA3x41pRYZE/gRAtxLAKDKCpFooWEpuPrQ+QKaZFWKntp8jwCgg/st m5sIT/JB03xZC4SdQDnRBYk= =R37G -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: | Derek Price [EMAIL PROTECTED] writes: | | I thought Mark was just saying earlier in this thread that | .trunk.root, by virtue of .root normally specifying a revision on | the parent branch, should refer to the `0' revision? | | | Hmmm... I may be getting confused, I thought .trunk.root.prev would | be the `0' revision, but if you are right then .trunk.root.next | would be the same as .origin right? No. I think 0.next would be an invalid construct, or also return 0. If you take this off the trunk, this might make more sense: BRANCH.root is on the trunk (or another branch), so BRANCH.root.next would return the revision following the root revision on the parent. For example, 1.2.2.7.root would return 1.2. Since 1.2.next yields 1.3, then 1.2.2.7.root.next should also yield 1.3. Since there is no revision following on the `0 branch', .trunk.root.next should either also be 0 or be invalid. | As for `0', we probably need to be more consistent about it... for | example, the command: | | cvs rdiff -r0 -r1.1 foo-module/foo-file | | yeilds a diff against /dev/null of the foo-file while the commands | | cvs co foo-module cd foo-module cvs diff -r0 -r1.1 foo-file | | yeilds an error message: | | 'cvs diff: tag 0 is not in file foo-file' | | this probably needs to be `fixed' to do something reasonable with | `0' for most uses as a phantom revision that exists before the file | existed on the branch or trunk. I agree. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJ0c2LD1OTBfyMaQRAj0dAJ9Qt/gkL2Vunx6y6A0GB4qxF+rqCwCgjrtr EnCQIIQjVKK4dNM8unXhwAY= =3dZx -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: No. I think 0.next would be an invalid construct, or also return 0. Yeah, you are correct. If you take this off the trunk, this might make more sense: BRANCH.root is on the trunk (or another branch), so BRANCH.root.next would return the revision following the root revision on the parent. For example, 1.2.2.7.root would return 1.2. Since 1.2.next yields 1.3, then 1.2.2.7.root.next should also yield 1.3. Yup. Since there is no revision following on the `0 branch', .trunk.root.next should either also be 0 or be invalid. Agreed. Given that 1.2.2.7.root == 1.2 which is the predicessor revision to the first revision on the branch, and .trunk being on the TRUNK, then .trunk.root is the predicessor revision for the TRUNK also known as `0'. Therefore, I suppose that there could be a need for .origin to be the first revision on TRUNK and .trunk.head to replace HEAD on TRUNK. Looking at a mixture of the modifiers with regard to time... One presumes that '.trunk:2005-03-01 08:00:00 UTC' would be the revision that was committed just before 2005-03-01 08:00:00 UTC. It is less clear how one would specify the .next revision on the TRUNK for that case... -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJ1uH3x41pRYZE/gRAsoZAKCfPuDJHWrt+y3Qtwk2AfGe9inw1ACgyQub /m83ZvvHmEFzVQtDX8fo78k= =2HUw -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: | Therefore, I suppose that there could be a need for .origin to be | the first revision on TRUNK This would seldom mean much across multiple files, so I still think .origin should not be used. The case Frank cited, where he is basically trying to diff against an import (thought not generated using the import command), is the only one where all the .origin revisions will be related in a sensible way, and even then only if no files have been added or removed on the trunk. Once files have been added or removed, you degenerate to the case where the .origin revisions (or even 1.1 revisions) of these files could have been added at different times and offering to calculate .origin is misleading at best. The only consistent way to do this is to tag everything after the import and diff against that tag. This tag couldn't even really be automated, except in something like the import command, which imports a set of files at once and tags the set. .origin makes no sense. | Looking at a mixture of the modifiers with regard to time... | | One presumes that '.trunk:2005-03-01 08:00:00 UTC' would be the | revision that was committed just before 2005-03-01 08:00:00 UTC. It | is less clear how one would specify the .next revision on the TRUNK | for that case... As this stands, with : and . already overloaded in time specs, this could get complex, but I will grant that the feature might be nice once the syntax was ironed out. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJ2InLD1OTBfyMaQRAl2tAJ9e8+0pKMDCVkgBBpoSE75JKMZq2QCgrrAB ab9OQ+bJzuJmZMOaqDjOCCo= =7Iy6 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
On Wednesday 02 March 2005 17:18, Derek Price wrote: Frank Hemer wrote: | On Wednesday 02 March 2005 08:11, Mark D. Baushke wrote: | Hi Frank, | | I am looking forward to your feature... | | :-) I'm looking forward to this too. I just have one quibble, with your usage of .root. The CVS manual and other sources use root to refer to what you are referring to as the origin of a branch. The logic being that a branch is always rooted in another branch, so the root refers to the revision actually on the parent branch. I'm not sure what I would recommend in place of what you are calling the root, but I would like to see .root refer to the revision on the parent branch. Not a problem, its just a #define. However I didn't have a better idea. Using .base instead can be similar miss-interpreted since there is BASE. How about replacing '.root' with '.tail', and replacing '.origin' with '.root'? The rest of your design looks great so far! :-) Regards, Frank -- - The LinCVS Team - http:/www.lincvs.com ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | On Wednesday 02 March 2005 08:11, Mark D. Baushke wrote: | | Hi Frank, | | I am looking forward to your feature... | | | :-) I'm looking forward to this too. I just have one quibble, with your usage of .root. The CVS manual and other sources use root to refer to what you are referring to as the origin of a branch. The logic being that a branch is always rooted in another branch, so the root refers to the revision actually on the parent branch. I'm not sure what I would recommend in place of what you are calling the root, but I would like to see .root refer to the revision on the parent branch. The rest of your design looks great so far! Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJedoLD1OTBfyMaQRArgNAJ48jg/auVzUf1wPGhzSnycAJemgHQCgun91 /bXDmBy8bg1tuxjZxO7Uejk= =G0xj -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | Not a problem, its just a #define. However I didn't have a better | idea. Using .base instead can be similar miss-interpreted since | there is BASE. How about replacing '.root' with '.tail', and | replacing '.origin' with '.root'? Yeah, that's great. I like that. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJe+hLD1OTBfyMaQRAt4iAKDIx4GzGyw8DNMS5pSXVcmWSmpP5ACg9527 OhhJ/diIcGzF0n/HIq2DuX0= =GOu/ -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
Derek Price writes: I'm not sure what I would recommend in place of what you are calling the root, but I would like to see .root refer to the revision on the parent branch. As far as I can see, what Frank is calling the root is meaningless in CVS. I'd just get rid of it. -Larry Jones Temporary insanity! That's all it was! -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: I just have one quibble, with your usage of .root. The CVS manual and other sources use root to refer to what you are referring to as the origin of a branch. The logic being that a branch is always rooted in another branch, so the root refers to the revision actually on the parent branch. Good point. I'm not sure what I would recommend in place of what you are calling the root, but I would like to see .root refer to the revision on the parent branch. I agree. That would be less confusing. Maybe .first should indicate the first revision on a branch? '.first': Will always resolve to the first revision on a branch (1.4.2.6.20.root will resolve to 1.4.2.6.1 [assuming that the *.1 version of this branch has not been deleted]). '.root': Will resolv to .first.prev, meaning the predecessor of the first revision on the branch. '.trunk': The most recently commited revision of the mainline. If I have a file that has always just been imported the file, and it is therefore still using a 'branch 1.1.1;' in the RCS file, the .trunk the most recently imported version (possibly something like 1.1.1.96). If an imported file were modified and committed, the first version might be 1.2 and .trunk would be 1.2 in that case. .trunk.first would usually be version 1.1 unless someone had started that file initially on a branch in which case .trunk.first might be 1.2 where 1.1 was a dead revision. .trunk.first.prev would be 0 as a way of getting a diff between /dev/null and whatever other version was being compared. The above is NOT what Frank has proposed, it is just a possible renaming... The rest of your design looks great so far! I Agree! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJfPO3x41pRYZE/gRAtEHAJ0Y9f8qSd+o6nNMEBg96peLl0hPFQCg4mi/ vgdGOLAzGwu2BO7WM5mVqRY= =GSLO -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer [EMAIL PROTECTED] writes: However I didn't have a better idea. Using .base instead can be similar miss-interpreted since there is BASE. How about replacing '.root' with '.tail', and replacing '.origin' with '.root'? Hmmm... I like replacing '.origin' with '.root' and I agree that .base is too confusing with BASE. I have a mild dislike of '.tail' even though it does have some symmetry with HEAD... (I keep thinking that 'tail file' gives me the latest bits appended to the file.) If you don't like '.first' (mentioned in a previous e-mail), perhaps '.branch' is a another alternative name that could be used as the first revision on the branch? -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJfXP3x41pRYZE/gRAk/JAJ97BT7DuULnxk/JQekzWDn6xD0tbgCeJLSg p80lIMBfQqQCXaZl/kzz1C0= =TA9V -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: | Frank Hemer [EMAIL PROTECTED] writes: | | However I didn't have a better idea. Using .base instead can be | similar | miss-interpreted since there is BASE. How about replacing '.root' | with '.tail', and replacing '.origin' with '.root'? | | | Hmmm... I like replacing '.origin' with '.root' and I agree that | .base is too confusing with BASE. I have a mild dislike of '.tail' | even though it does have some symmetry with HEAD... (I keep | thinking that 'tail file' gives me the latest bits appended to the | file.) Actually, I was waiting for Frank to finish his patch, but, when he was done, I was going to insert .base as a synonym for BASE, and .head as the head of the current (possibly sticky) branch, and deprecate HEAD and BASE to clear the namespace. Then .trunk.head would be a synonym for the old HEAD, BRANCH.head could be used to explicitly specify the head of any branch, and .head would refer to the head of the sticky branch in the current workspace. | If you don't like '.first' (mentioned in a previous e-mail), | perhaps '.branch' is a another alternative name that could be used | as the first revision on the branch? Actually, the revision specified by .tail is meaningless to CVS, as Larry pointed out. It had occurred to me that it was pretty meaningless earlier, but on further consideration, it is totally meaningless or worse than meaningless (in being potentially misleading) once it is applied to multiple files. There is no reason to expect that the *.1 branch revision of one file was committed even close to the same time as the *.1 revision of a second file, so such a specification across multiple files could only confuse a user expecting it to mean something. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJfyTLD1OTBfyMaQRAp4VAJwIcxGtZdBygmVoNANNl+XuG0FYqQCg+Ag8 Hq6ll1ifDJY5XRmQs72d4nE= =7KtA -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
Hi Derek, Mark D. Baushke wrote: | Frank Hemer [EMAIL PROTECTED] writes: | However I didn't have a better idea. Using .base instead can be | | similar | | miss-interpreted since there is BASE. How about replacing '.root' | with '.tail', and replacing '.origin' with '.root'? | | Hmmm... I like replacing '.origin' with '.root' and I agree that | .base is too confusing with BASE. I have a mild dislike of '.tail' | even though it does have some symmetry with HEAD... (I keep | thinking that 'tail file' gives me the latest bits appended to the | file.) Actually, I was waiting for Frank to finish his patch, but, when he was done, I was going to insert .base as a synonym for BASE, and .head as the head of the current (possibly sticky) branch, and deprecate HEAD and BASE to clear the namespace. Then .trunk.head would be a synonym for the old HEAD, BRANCH.head could be used to explicitly specify the head of any branch, and .head would refer to the head of the sticky branch in the current workspace. A rational way. As a second step I would suggest to change the extensions (.prev, .next, .xxx) to be allowed in head position too, but I'm note sure where the sandbox tag gets processed. If translate_tags() could take that into account, its not a big deal ... Where is this state cached? | If you don't like '.first' (mentioned in a previous e-mail), | perhaps '.branch' is a another alternative name that could be used | as the first revision on the branch? Actually, the revision specified by .tail is meaningless to CVS, as Larry pointed out. It had occurred to me that it was pretty meaningless earlier, but on further consideration, it is totally meaningless or worse than meaningless (in being potentially misleading) once it is applied to multiple files. There is no reason to expect that the *.1 branch revision of one file was committed even close to the same time as the *.1 revision of a second file, so such a specification across multiple files could only confuse a user expecting it to mean something. So probably the expression used should connote this. After some consideration, I would vote for '.origin' here. I disagree with being meaningless. I often export a project state into a local repository, work on it, and when I'm done, move the files back to the remote repository's sandbox. During local development I often want to compare to the initial version of a file, and using a single tag for this is just easy. Granted there are other ways to achieve this, but they're not as easy to handle. Regards, Frank -- - The LinCVS Team - http://www.lincvs.com ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | Hi Derek, | | Mark D. Baushke wrote: | Frank Hemer [EMAIL PROTECTED] writes: | | However I didn't have a better idea. Using .base instead can be | | | similar | | miss-interpreted since there is BASE. How about | replacing '.root' | with '.tail', and replacing '.origin' with | '.root'? | | Hmmm... I like replacing '.origin' with '.root' and | I agree that | .base is too confusing with BASE. I have a mild | dislike of '.tail' | even though it does have some symmetry with | HEAD... (I keep | thinking that 'tail file' gives me the latest | bits appended to the | file.) | | Actually, I was waiting for Frank to finish his patch, but, when | he was done, I was going to insert .base as a synonym for BASE, | and .head as the head of the current (possibly sticky) branch, | and deprecate HEAD and BASE to clear the namespace. Then | .trunk.head would be a synonym for the old HEAD, BRANCH.head | could be used to explicitly specify the head of any branch, and | .head would refer to the head of the sticky branch in the current | workspace. | | | A rational way. As a second step I would suggest to change the | extensions (.prev, .next, .xxx) to be allowed in head position too, | but I'm note sure where the sandbox tag gets processed. If | translate_tags() could take that into account, its not a big deal | ... Where is this state cached? It's cached in the CVS/Entries files in each subdir. CVS looks it up in the Version_TS in vers_ts.c and decides to set it in the Vers_TS structure it returns only if the TAG passed to the function (via -r or something, somewhere) is not set. I think it could be caught there - if the TAG is .XXX (and not .trunk), then set the vers_ts-tag to STICKY.XXX. | | If you don't like '.first' (mentioned in a previous e-mail), | | perhaps '.branch' is a another alternative name that could be | used | as the first revision on the branch? | | Actually, the revision specified by .tail is meaningless to CVS, | as Larry pointed out. It had occurred to me that it was pretty | meaningless earlier, but on further consideration, it is totally | meaningless or worse than meaningless (in being potentially | misleading) once it is applied to multiple files. There is no | reason to expect that the *.1 branch revision of one file was | committed even close to the same time as the *.1 revision of a | second file, so such a specification across multiple files could | only confuse a user expecting it to mean something. | | | So probably the expression used should connote this. After some | consideration, I would vote for '.origin' here. I disagree with | being meaningless. I often export a project state into a local | repository, work on it, and when I'm done, move the files back to | the remote repository's sandbox. During local development I often | want to compare to the initial version of a file, and using a | single tag for this is just easy. Granted there are other ways to | achieve this, but they're not as easy to handle. That's fine for 1.1, but how does this help you for a branch? You might want to diff against the root, but it doesn't make much sense to care about the first revision on the branch. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJolFLD1OTBfyMaQRAh9PAKDgLls52frl/SMVxSmD9ntd6LPXpACfc44B pfkbw4qcnV+aP6sM4PlBy3g= =Esmc -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
Note that when the final flag to tag_check_valid() is true,
tag_check_valid() skips step 2 (the recursive repository check) and
jumps to adding the tag to val-tags.
Is this a security issue, meaning to reduce server load if lots of invalid tags
are requested?
However, I have implemented it that way, also adding tag_check_valid(...,true)
to import.c and commit.c
Tags now can be combined of several subexpressions, each separated by a dot.
Tags that must be at the begining of the tag:
1. '.commitid' (backwd. compatible as '@') followed by the id
2. '.trunk' may be used as a TRUNK branch
Extensions that might follow such a tag (or a numeric/symbolic tag):
1. '.prev' - meaning the previous revision on the current branch or trunk
2. '.next' - meaning the next revision on the current branch or trunk
3. '.root' - meaning the first revision on the current branch or trunk
4. '.origin' - meaning the revision a branch-revision or branch is based on:
1.4.2.5.origin = 1.4
All extensions can be appended several times. No rule without an exception, the
'.root' extension
cannot be appended to itself, it needs a different extension in between.
Example 1.4.2.5.root.prev == 1.4.2.5.origin == 1.4.prev.next == 1.4
sanity.sh runs ok, but I would like to receive some feedback ...
Here's the patch agains the current repo version:
Index: src/commit.c
===
RCS file: /home/frank/CVS_ROOT/ccvs/src/commit.c,v
retrieving revision 1.1.1.2
retrieving revision 1.4
diff -u -r1.1.1.2 -r1.4
--- src/commit.c2 Mar 2005 01:36:28 - 1.1.1.2
+++ src/commit.c2 Mar 2005 01:40:09 - 1.4
@@ -698,6 +698,10 @@
Lock_Cleanup ();
dellist (mulist);
+char *commitid = Xasprintf (@%s, global_session_id);
+tag_check_valid (commitid, argc, argv, local, aflag, , true);
+free (commitid);
+
/* see if we need to sleep before returning to avoid time-stamp races */
if (
#ifdef SERVER_SUPPORT
@@ -884,13 +888,16 @@
finfo-fullname);
goto out;
}
- if (status == T_MODIFIED vers-tag
- !RCS_isbranch (finfo-rcs, vers-tag))
+ if (status == T_MODIFIED vers-tag)
{
- error (0, 0,
- sticky tag `%s' for file `%s' is not a branch,
- vers-tag, finfo-fullname);
- goto out;
+ if ( (*(vers-tag) != '.' || strcmp (vers-tag+1, TAG_TRUNK))
+ !RCS_isbranch (finfo-rcs, vers-tag) )
+ {
+ error (0, 0,
+ sticky tag `%s' for file `%s' is not a branch,
+ vers-tag, finfo-fullname);
+ goto out;
+ }
}
}
if (status == T_MODIFIED !force_ci vers-ts_conflict)
Index: src/cvs.h
===
RCS file: /home/frank/CVS_ROOT/ccvs/src/cvs.h,v
retrieving revision 1.1.1.1
retrieving revision 1.5
diff -u -r1.1.1.1 -r1.5
--- src/cvs.h 27 Feb 2005 15:02:24 - 1.1.1.1
+++ src/cvs.h 1 Mar 2005 20:30:05 - 1.5
@@ -242,6 +242,12 @@
*/
#defineTAG_HEADHEAD
#defineTAG_BASEBASE
+#define TAG_COMMITIDcommitid
+#define TAG_PREVIOUSprev
+#define TAG_TRUNK trunk
+#define TAG_ORIGIN origin
+#define TAG_ROOTroot
+#define TAG_NEXTnext
/* Environment variable used by CVS */
#defineCVSREAD_ENV CVSREAD /* make files read-only */
Index: src/import.c
===
RCS file: /home/frank/CVS_ROOT/ccvs/src/import.c,v
retrieving revision 1.1.1.1
retrieving revision 1.3
diff -u -r1.1.1.1 -r1.3
--- src/import.c27 Feb 2005 15:02:24 - 1.1.1.1
+++ src/import.c1 Mar 2005 12:41:18 - 1.3
@@ -440,6 +440,10 @@
error (0, errno, cannot remove %s, tmpfile);
free (tmpfile);
+char *commitid = Xasprintf (@%s, global_session_id);
+tag_check_valid (commitid, 0, NULL, 0, 1, NULL, true);
+free (commitid);
+
if (message)
free (message);
free (repository);
Index: src/rcs.c
===
RCS file: /home/frank/CVS_ROOT/ccvs/src/rcs.c,v
retrieving revision 1.1.1.2
retrieving revision 1.14
diff -u -r1.1.1.2 -r1.14
--- src/rcs.c 28 Feb 2005 21:55:36 - 1.1.1.2
+++ src/rcs.c 2 Mar 2005 01:27:01 - 1.14
@@ -65,6 +65,8 @@
};
static RCSNode *RCS_parsercsfile_i (FILE * fp, const char *rcsfile);
+static char *RCS_getdatetrunk (RCSNode * rcs, const char *date,
+ int force_tag_match);
static char *RCS_getdatebranch (RCSNode * rcs, const char *date,
const char *branch);
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | On Saturday 26 February 2005 21:06, Derek Price wrote: | | Frank Hemer wrote: | On Saturday 26 February 2005 00:27, Derek | Price wrote: | Frank Hemer wrote: | I was just glancing at that | patch and I | think I can implement | what Steve did much more | succinctly, so | I'm going to take a shot | at it. The most | important thing for | your patch is probably to use | the | naming scheme: `.XXX'. | | | So I'll wait for your commit then. | | | Here's a question: Should the commitids be cached in | | CVSROOT/val-tags in some form? I think so. What is CVSNT doing | | in this regard? | | Cvsnt seems not to cache the commitids. I | don't think it is | reasonable to cache here because _every_ | commit would be cached, | bloating val-tags but not gaining any | performance. | | Actually, the trick with val-tags is that it is much cheaper to | search the dbm file than it is to parse and search each and every | RCS file when looking for a tag that may only exist in a single | file. Even with a lot of commits, it will remain cheaper to | search the val-tags file, I would hazard. | | | Well, actually the commitid isn't a tag ... However, I added it in | tag.c::tag_check_valid() to play around ... | | Though it's not yet being done, the current recursive RCS file | tag search could be made more efficient by only parsing the RCS | header when validating tags. This won't work with commitids, | since they are stored with the revision data, adding more reason | for adding them to val-tags. | | It's possible that if DBM search performance ever becomes an | issue, we could move to some sort of sorted (and indexed? | binary?) dbm type that is cheaper to search. | | | Good Idea, this would open ways to implement a real 'rename' and | 'move' feature ... | | I have pasted my current patch state, there is no docu yet, and no | sanity.sh testing. However, the current sanity.sh is not affected | by the patch, and still runs ok. | | Features: 1) .commitid.xxx will select the revision when used as a | tag 2) appending '.prev' to a numeric revision or a symbolic tag | will select the previous revision | | Probably more testing needs to be done, but I'll wait for feedback | ... Unfortunately my mail-client refuses to switch of line | wrapping, but I'll care about it another time:-( The patch looks pretty good. It's pretty close to what I am doing, except I am splitting tags with operators (.word) on the `.' and then processing the resulting list an element at a time. Thus .prev can be implemented for each and every revision specification type in a single location (as opposed to in a special case inside an `if (commitid)' block. Regardless, what you are doing should mesh pretty well with what I am working on once it has sanity.sh test cases and doc. I still think commitids should be cached in val-tags. Probably as [EMAIL PROTECTED]' just to keep it short where the user cannot see it anyhow. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCI0/wLD1OTBfyMaQRAjjWAKD5I6EA3Unbh9laXpe06RmYnzx/YQCg+PHc QS8xCOz0Us27aCgwVflwumE= =X3ZL -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
| Ooops, I think I'm too fast;-) I have just finished adding '.trunk' | as a trunk-branch substitution, 'cause I happened to note that this | fits perfectly into my patch. I have already used the above | mentioned splitting - so now '.prev' might even be added more than | once and works perfectly well:-) Great! Less work for me. :) You could do me a big favor if you later would add some test cases to sanity.sh ... | I still think commitids should be cached in val-tags. Probably | as [EMAIL PROTECTED]' just to keep it short where the user cannot see it | anyhow. | | I currently have added this: | | If tags with '@' at the begining are used they're added in the | cvsnt way (I remember I wrote cvsnt wouldn't cache them but I was | wrong). If the .commitid is used, they're cached as | '.commitid.xxx', but this could be changed as you suggested. I think this would be a good idea, as otherwise the search of val-tags will be run once for each possible form of the commitid. So I need a suggestion, cvsnt seems to cache the whole commitid, for example: '@123f456a789b' or even worse: '@123f456a789b' probably its best to change it all to '@commitid'? Also, commitids should be cached at commit time as well as when they are found in RCS files. CVS started doing this on tag creation for other branches and tags a few releases back It's silly to wait for the first update to insert them into val-tags - it only triggers an unneeded recursive search. I saw tag.c::tag_check_valid(). Are there other locations where val-tags entries are added/accessed? Regards, Frank -- - The LinCVS Team - http:/www.lincvs.com ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | The patch looks pretty good. It's pretty close to what I am | doing, except I am splitting tags with operators (.word) on the | `.' and then processing the resulting list an element at a time. | Thus .prev can be implemented for each and every revision | specification type in a single location (as opposed to in a | special case inside an `if (commitid)' block. | | Regardless, what you are doing should mesh pretty well with what | I am working on once it has sanity.sh test cases and doc. | | | Ooops, I think I'm too fast;-) I have just finished adding '.trunk' | as a trunk-branch substitution, 'cause I happened to note that this | fits perfectly into my patch. I have already used the above | mentioned splitting - so now '.prev' might even be added more than | once and works perfectly well:-) Great! Less work for me. :) | I still think commitids should be cached in val-tags. Probably | as [EMAIL PROTECTED]' just to keep it short where the user cannot see it | anyhow. | | | I currently have added this: | | If tags with '@' at the begining are used they're added in the | cvsnt way (I remember I wrote cvsnt wouldn't cache them but I was | wrong). If the .commitid is used, they're cached as | '.commitid.xxx', but this could be changed as you suggested. I think this would be a good idea, as otherwise the search of val-tags will be run once for each possible form of the commitid. Also, commitids should be cached at commit time as well as when they are found in RCS files. CVS started doing this on tag creation for other branches and tags a few releases back It's silly to wait for the first update to insert them into val-tags - it only triggers an unneeded recursive search. | I'll post my patch after some more cleanups ... soon;-) Sounds good. I'm looking forward to seeing your patch! Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCI1fPLD1OTBfyMaQRArylAKCabLXEc+rgTVY+96MfA3zcUS9BYACfUZaf iuurhI/dCuLyPXo1UVFSjA0= =n+Hf -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
| If tags with '@' at the begining are used they're added in the | cvsnt way (I remember I wrote cvsnt wouldn't cache them but I was | wrong). If the .commitid is used, they're cached as | '.commitid.xxx', but this could be changed as you suggested. I think this would be a good idea, as otherwise the search of val-tags will be run once for each possible form of the commitid. Comming back on this issue: In tag.c::tag_check_valid() there is a consistency check for symbolic tags before adding the tag to val-tags. Because this consistency-check now properly identifies the commitid tag, it usually would never be added to val-tags, and I don't see any other place where val-tags is accessed. So I would assume not adding to val-tags makes no difference if the tag_check_valid() is never called for the commitid, even better, it saves some performance? Do I miss sth.? Regards, Frank -- - The LinCVS Team - http:/www.lincvs.com ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | | If tags with '@' at the begining are used they're added in | the | cvsnt way (I remember I wrote cvsnt wouldn't cache them | but I was | wrong). If the .commitid is used, they're cached as | | '.commitid.xxx', but this could be changed as you suggested. | | | I think this would be a good idea, as otherwise the search of | val-tags will be run once for each possible form of the | commitid. | | | Comming back on this issue: In tag.c::tag_check_valid() there is a | consistency check for symbolic tags before adding the tag to | val-tags. Because this consistency-check now properly identifies | the commitid tag, it usually would never be added to val-tags, and | I don't see any other place where val-tags is accessed. So I would | assume not adding to val-tags makes no difference if the | tag_check_valid() is never called for the commitid, even better, it | saves some performance? Do I miss sth.? The commitid algorithm should be the same as for other tags, here: ~ 1. When tag is created, add it to val-tags (in the case of ~ commitids, tag_check_valid(..., true) will be called somewhere ~ in commit.c). ~ 2. In tag_check_valid(): ~ 1. Check if tag exists in val-tags. If it does return true. ~ 2. Check if tag exists in RCS files in the repository. If ~not, return false. ~ 3. Add the tag to val-tags. ~ 4. Return true. Note that when the final flag to tag_check_valid() is true, tag_check_valid() skips step 2 (the recursive repository check) and jumps to adding the tag to val-tags. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCI4EhLD1OTBfyMaQRAoHOAKD8ihgUPyDc6IJdTeRaR6yGO6bSxACg5oJJ P1iJt5fPyFPnTVtvCEjeLxM= =gIIY -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | | Ooops, I think I'm too fast;-) I have just finished adding | '.trunk' | as a trunk-branch substitution, 'cause I happened to | note that this | fits perfectly into my patch. I have already | used the above | mentioned splitting - so now '.prev' might even | be added more than | once and works perfectly well:-) | | Great! Less work for me. :) | | | You could do me a big favor if you later would add some test cases | to sanity.sh ... We'll see when the time comes, but I'm not going to have a whole lot of free time for a few weeks at least, unfortunately. | | I still think commitids should be cached in val-tags. | Probably | as [EMAIL PROTECTED]' just to keep it short where the user | cannot see it | anyhow. | | I currently have added this: | | If | tags with '@' at the begining are used they're added in the | | cvsnt way (I remember I wrote cvsnt wouldn't cache them but I was | | wrong). If the .commitid is used, they're cached as | | '.commitid.xxx', but this could be changed as you suggested. | | I think this would be a good idea, as otherwise the search of | val-tags will be run once for each possible form of the commitid. | | | | So I need a suggestion, cvsnt seems to cache the whole commitid, | for example: '@123f456a789b' or even worse: '@123f456a789b' | | probably its best to change it all to '@commitid'? Ah, now that's interesting. I think the answer is yes, though. The issue is whether a commitid attached to revision 1.1, which has no previous revision, should return an error when @commitid is requested. I think the answer is no, since I would assume that a user would want `cvs diff -r@commitid @commitid' to return something useful for a file added in the commit in question. | Also, commitids should be cached at commit time as well as when | they are found in RCS files. CVS started doing this on tag | creation for other branches and tags a few releases back It's | silly to wait for the first update to insert them into val-tags - | it only triggers an unneeded recursive search. | | | I saw tag.c::tag_check_valid(). Are there other locations where | val-tags entries are added/accessed? No, that is the only location. The trick is that you need a call like `tag_check_valid (@commitid, 0, NULL, 0, 0, NULL, true);' in commit.c after you are certain that the commitid has been added to at least one file. Should only call it once per commitid too, if possible. Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCI3zqLD1OTBfyMaQRAi2HAKCk5sVmyK+1LK2NQBFFZkO2ukT6iQCbB6/o W6VueNoHjoZl68xjTLOYLSc= =Ti6e -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
| Also, commitids should be cached at commit time as well as when
| they are found in RCS files. CVS started doing this on tag
| creation for other branches and tags a few releases back It's
| silly to wait for the first update to insert them into val-tags -
| it only triggers an unneeded recursive search.
A cannot find any call to tag_check_valid() with the final (valid) flag set to
true?
| I saw tag.c::tag_check_valid(). Are there other locations where
| val-tags entries are added/accessed?
No, that is the only location. The trick is that you need a call like
`tag_check_valid (@commitid, 0, NULL, 0, 0, NULL, true);' in
commit.c after you are certain that the commitid has been added to at
least one file. Should only call it once per commitid too, if possible.
I'll leave this for later ... now it's added like '@'.
Features:
'.trunk' works like a TRUNK branch
'.prev' can be appended to '.trunk', numeric rev. numbers, symbolic tags and
commitid's except for 'HEAD' and 'BASE'.
It can be appended several times ...
The '.prev' extension is not possible with 'x.x.x:date' because it would turn
any branch into a specific revision.
The formating might not stick to the cvs-rulses on some places? If so, I'll fix
it later.
Here's the patch, I hope I have successfully disabled the linewrapping ...
Index: src/cvs.h
===
RCS file: /home/frank/CVS_ROOT/ccvs/src/cvs.h,v
retrieving revision 1.1.1.1
retrieving revision 1.4
diff -u -r1.1.1.1 -r1.4
--- src/cvs.h 27 Feb 2005 15:02:24 - 1.1.1.1
+++ src/cvs.h 28 Feb 2005 16:55:03 - 1.4
@@ -242,6 +242,9 @@
*/
#defineTAG_HEADHEAD
#defineTAG_BASEBASE
+#define TAG_COMMITIDcommitid
+#define TAG_PREVIOUSprev
+#define TAG_TRUNK trunk
/* Environment variable used by CVS */
#defineCVSREAD_ENV CVSREAD /* make files read-only */
Index: src/rcs.c
===
RCS file: /home/frank/CVS_ROOT/ccvs/src/rcs.c,v
retrieving revision 1.1.1.2
retrieving revision 1.10
diff -u -r1.1.1.2 -r1.10
--- src/rcs.c 28 Feb 2005 21:55:36 - 1.1.1.2
+++ src/rcs.c 28 Feb 2005 21:57:57 - 1.10
@@ -65,6 +65,8 @@
};
static RCSNode *RCS_parsercsfile_i (FILE * fp, const char *rcsfile);
+static char *RCS_getdatetrunk (RCSNode * rcs, const char *date,
+ int force_tag_match);
static char *RCS_getdatebranch (RCSNode * rcs, const char *date,
const char *branch);
static void rcsbuf_open (struct rcsbuffer *, FILE *fp,
@@ -94,6 +96,8 @@
static void free_rcsnode_contents (RCSNode *);
static void free_rcsvers_contents (RCSVers *);
static void rcsvers_delproc (Node * p);
+static char *RCS_findcommitid (RCSNode *, const char *, bool);
+static char *translate_tag (RCSNode *, const char *);
static char *translate_symtag (RCSNode *, const char *);
static char *RCS_addbranch (RCSNode *, const char *);
static char *truncate_revnum_in_place (char *);
@@ -2126,23 +2130,30 @@
{
char *branch, *rev;
- if (! RCS_nodeisbranch (rcs, tag))
+ if (*tag == '.' !strcmp (tag+1, TAG_TRUNK))
{
- /* We can't get a particular date if the tag is not a
- branch. */
- return NULL;
+ return RCS_getdatetrunk (rcs, date, force_tag_match);
}
-
- /* Work out the branch. */
- if (! isdigit ((unsigned char) tag[0]))
- branch = RCS_whatbranch (rcs, tag);
else
- branch = xstrdup (tag);
+ {
+ if (! RCS_nodeisbranch (rcs, tag))
+ {
+ /* We can't get a particular date if the tag is not a
+ branch. */
+ return NULL;
+ }
- /* Fetch the revision of branch as of date. */
- rev = RCS_getdatebranch (rcs, date, branch);
- free (branch);
- return rev;
+ /* Work out the branch. */
+ if (! isdigit ((unsigned char) tag[0]))
+ branch = RCS_whatbranch (rcs, tag);
+ else
+ branch = xstrdup (tag);
+
+ /* Fetch the revision of branch as of date. */
+ rev = RCS_getdatebranch (rcs, date, branch);
+ free (branch);
+ return rev;
+ }
}
else if (tag)
return RCS_gettag (rcs, tag, force_tag_match, simple_tag);
@@ -2235,8 +2246,8 @@
if (tag STREQ (tag, TAG_HEAD))
return RCS_head (rcs);
-/* If valid tag let translate_symtag say yea or nay. */
-rev = translate_symtag (rcs, tag);
+/* If valid tag let translate_tag say yea or nay. */
+rev = translate_tag (rcs, tag);
if (rev)
return rev;
@@ -2282,12 +2293,12 @@
#endif
return RCS_head (rcs);
-if (!isdigit ((unsigned char) symtag[0]))
+if (!isrevnumonly (symtag))
{
char
Re: Feature request/ideas
On Saturday 26 February 2005 00:27, Derek Price wrote: Frank Hemer wrote: | I was just glancing at that patch and I think I can implement | what Steve did much more succinctly, so I'm going to take a shot | at it. The most important thing for your patch is probably to use | the naming scheme: `.XXX'. | | So I'll wait for your commit then. Here's a question: Should the commitids be cached in CVSROOT/val-tags in some form? I think so. What is CVSNT doing in this regard? Cvsnt seems not to cache the commitids. I don't think it is reasonable to cache here because _every_ commit would be cached, bloating val-tags but not gaining any performance. Regards, Frank -- - The LinCVS Team - http:/www.lincvs.com ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | On Saturday 26 February 2005 00:27, Derek Price wrote: | | Frank Hemer wrote: | I was just glancing at that patch and I | think I can implement | what Steve did much more succinctly, so | I'm going to take a shot | at it. The most important thing for | your patch is probably to use | the naming scheme: `.XXX'. | | | So I'll wait for your commit then. | | Here's a question: Should the commitids be cached in | CVSROOT/val-tags in some form? I think so. What is CVSNT doing | in this regard? | | | Cvsnt seems not to cache the commitids. I don't think it is | reasonable to cache here because _every_ commit would be cached, | bloating val-tags but not gaining any performance. Actually, the trick with val-tags is that it is much cheaper to search the dbm file than it is to parse and search each and every RCS file when looking for a tag that may only exist in a single file. Even with a lot of commits, it will remain cheaper to search the val-tags file, I would hazard. Though it's not yet being done, the current recursive RCS file tag search could be made more efficient by only parsing the RCS header when validating tags. This won't work with commitids, since they are stored with the revision data, adding more reason for adding them to val-tags. It's possible that if DBM search performance ever becomes an issue, we could move to some sort of sorted (and indexed? binary?) dbm type that is cheaper to search. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCINasLD1OTBfyMaQRAiVsAKCpksM7W/tJ92FwFp8JmmY9uvHRewCfQTbK Vq0QVD2WPfCmbK82p8RECig= =//g7 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
On Saturday 26 February 2005 21:06, Derek Price wrote:
Frank Hemer wrote:
| On Saturday 26 February 2005 00:27, Derek Price wrote:
| Frank Hemer wrote: | I was just glancing at that patch and I
| think I can implement | what Steve did much more succinctly, so
| I'm going to take a shot | at it. The most important thing for
| your patch is probably to use | the naming scheme: `.XXX'. | |
| So I'll wait for your commit then.
|
| Here's a question: Should the commitids be cached in
| CVSROOT/val-tags in some form? I think so. What is CVSNT doing
| in this regard?
|
| Cvsnt seems not to cache the commitids. I don't think it is
| reasonable to cache here because _every_ commit would be cached,
| bloating val-tags but not gaining any performance.
Actually, the trick with val-tags is that it is much cheaper to search
the dbm file than it is to parse and search each and every RCS file
when looking for a tag that may only exist in a single file. Even
with a lot of commits, it will remain cheaper to search the val-tags
file, I would hazard.
Well, actually the commitid isn't a tag ...
However, I added it in tag.c::tag_check_valid() to play around ...
Though it's not yet being done, the current recursive RCS file tag
search could be made more efficient by only parsing the RCS header
when validating tags. This won't work with commitids, since they are
stored with the revision data, adding more reason for adding them to
val-tags.
It's possible that if DBM search performance ever becomes an issue, we
could move to some sort of sorted (and indexed? binary?) dbm type that
is cheaper to search.
Good Idea, this would open ways to implement a real 'rename' and 'move'
feature ...
I have pasted my current patch state, there is no docu yet, and no sanity.sh
testing. However, the current sanity.sh is not affected by the patch, and
still runs ok.
Features:
1) .commitid.xxx will select the revision when used as a tag
2) appending '.prev' to a numeric revision or a symbolic tag will select the
previous revision
Probably more testing needs to be done, but I'll wait for feedback ...
Unfortunately my mail-client refuses to switch of line wrapping, but I'll care
about it another time:-(
Index: src/cvs.h
===
RCS file: /cvs/ccvs/src/cvs.h,v
retrieving revision 1.330
diff -u -r1.330 cvs.h
--- src/cvs.h 26 Feb 2005 00:27:35 - 1.330
+++ src/cvs.h 26 Feb 2005 22:11:07 -
@@ -242,6 +242,8 @@
*/
#defineTAG_HEADHEAD
#defineTAG_BASEBASE
+#define TAG_COMMITID.commitid.
+#define TAG_PREVIOUSprev
/* Environment variable used by CVS */
#defineCVSREAD_ENV CVSREAD /* make files read-only */
Index: src/rcs.c
===
RCS file: /cvs/ccvs/src/rcs.c,v
retrieving revision 1.330
diff -u -r1.330 rcs.c
--- src/rcs.c 25 Feb 2005 17:54:04 - 1.330
+++ src/rcs.c 26 Feb 2005 22:11:12 -
@@ -94,6 +94,8 @@
static void free_rcsnode_contents (RCSNode *);
static void free_rcsvers_contents (RCSVers *);
static void rcsvers_delproc (Node * p);
+static char *RCS_findcommitid (RCSNode *, const char *, bool);
+static char *translate_tag (RCSNode *, const char *);
static char *translate_symtag (RCSNode *, const char *);
static char *RCS_addbranch (RCSNode *, const char *);
static char *truncate_revnum_in_place (char *);
@@ -2236,7 +2238,7 @@
return RCS_head (rcs);
/* If valid tag let translate_symtag say yea or nay. */
-rev = translate_symtag (rcs, tag);
+rev = translate_tag (rcs, tag);
if (rev)
return rev;
@@ -2262,6 +2264,7 @@
int *simple_tag)
{
char *tag;
+char *version;
if (simple_tag != NULL)
*simple_tag = 0;
@@ -2282,12 +2285,13 @@
#endif
return RCS_head (rcs);
-if (!isdigit ((unsigned char) symtag[0]))
+/* if (!isdigit ((unsigned char) symtag[0])) */
+if (!isrevnumonly (symtag))
{
char *version;
/* If we got a symbolic tag, resolve it to a numeric */
- version = translate_symtag (rcs, symtag);
+ version = translate_tag (rcs, symtag);
if (version != NULL)
{
int dots;
@@ -2517,10 +2521,14 @@
assert (rcs != NULL);
/* numeric revisions are easy -- even number of dots is a branch */
-if (isdigit ((unsigned char) *rev))
- return (numdots (rev) 1) == 0;
+/* if (isdigit ((unsigned char) *rev)) */
+/* return (numdots (rev) 1) == 0; */
+
+/* version = translate_symtag (rcs, rev); */
+if (isrevnumonly (rev))
+return (numdots (rev) 1) == 0;
-version = translate_symtag (rcs, rev);
+version = translate_tag (rcs, rev);
if (version == NULL)
return 0;
dots = numdots (version);
@@ -2571,7 +2579,7 @@
return NULL;
/* now, look for a match in the symbols list */
-
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | On Thursday 24 February 2005 17:03, Derek Price wrote: | | Frank Hemer wrote: | I have added support for the commitid in | about the same manner as | it is implemented in cvsnt, so this | shouldn't be a compatibility | issue. However, the commitid is as | well added to the 1.1 and | 1.1.1.1 revisions at the initial | import. | | Here goes the patch: | | This patch looks pretty good at first glance, but it needs test | cases in src/sanity.sh and documentation in doc/RCSFILES and | doc/cvs.texinfo before it may be committed. Please see the | HACKING file from the source distribution for more on the CVS | patch acceptance policy, and the TESTS file on how to write | sanity.sh test cases. | | | Once again, here it is: | | Index: ChangeLog | === | RCS file: /cvs/ccvs/ChangeLog,v retrieving revision 1.1162 Glancing at your doc and test cases, I gather that this change just tags the revisions and does not yet provide a way to get at the information for diffs/merges/etc.? Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCHzGnLD1OTBfyMaQRAgfJAKDQeM3V6BvDmukm8/kxCVCXPPHHcQCg4JX9 ZHKTTMfZ/j3noNomG0NGZps= =Jceg -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
Glancing at your doc and test cases, I gather that this change just tags the revisions and does not yet provide a way to get at the information for diffs/merges/etc.? That's right. I didn't like the way cvsnt evaluates tages - or better - the commitid tags. Because this is related to the general enhancement of tags (.previous and alike), I'm looking forward to your suggested shot at implementing Steve Cameron's idea/patch. Maybe (probably?) this will allow a better approach? However, the current patch allows log and status output to be parsed for the commitid on the client side - to identify related revisions. Btw: The cvsnt uses commitid tags in the following manner: @commitid: the specific commit @commitid: the previous commit The id is evaluated in rcs.c::translate_symtag(), adding just a few lines would add this all, but imho that solution is not the best. It's a matter of compatibility: If we want to stay compatible with cvsnt, we have to follow the same policy ... My personal preference would at least be to use sth. more clear like 'id:' to identify a symbolic tag as a commitid, instead of the '@' char. But most likely that's not worth breaking compatibility ... maybe allow both??? What do others think about this? Regards Frank ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
How about .commitid./commitid/ (where /commitid/ is replaced with
the actual commitid), with @ as an acceptable alias for .commitid.
for compatibility with CVSNT? Then .commitid./commitid/.previous or
@/commitid/ could be used to specify the previous revision.
So the '.' (dot) would generally act as a separator for combined tags?
I'll give it a shot -
I noted a typo in my patch for doc/cvs.texinfo, '@ref{status}' should be
replaced with '@ref{File status}'
Regards
Frank
--
- The LinCVS Team -
http:/www.lincvs.com
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: | FYI... | | I think I have been able to reconstruct the original patch without | linewrap... I don't know if I'll have time to really test it this | week, so Derek may feel free to commit it if he thinks it is ready | to go (modulo adding the missing src/ChangeLog and | src/doc/ChangeLog entries). Okay, looks like you got it Mark, except that some of the commitid: lines still needed two spaces before them. Frank, you're not quite hitting the preferred code formatting described in the HACKING file. If you could try to imitate that more closely next time, it would be appreciated. Also, I don't think it is mentioned there, but we tend to prefer Xasprintf to xmallox/sprintf or sprintfing to statically allocated strings. Since Xasprintf determines the length of the output string accurately and dynamically, it is less prone to opening up memory overflow issues, exploitable or otherwise. Thanks for the patch! I've committed it with a few minor changes re the above, though I left most of the formatting alone for now since it wasn't too far off. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCH2sZLD1OTBfyMaQRArytAJ9Xo0+PjWFzLnEvE3uGVDROyx1sswCg3og2 sJQfB/sHT1oYmMGy0ZnQJpQ= =yh2r -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
On Wednesday 23 February 2005 00:31, Derek Price wrote: Frank Hemer wrote: | In response to an old thread/message from dec 04, | (http://lists.gnu.org/archive/html/bug-cvs/2004-12/msg00150.html) I | would like to add some suggestions: | | The cvsnt commitid feature for the log cmd is a very neet feature | because it allows to collect all versions that belong to a single | commit. Yes, this would be nice. A patch will follow ... If your second part, above, were abstracted out such that the new revision-1 tag could be used anywhere CVS accepts two revision options (basically, diff update/commit -j), then this format could also be used to concisely back out a commit or to merge a specific commit to a new location. It's possible that something like `.previous' would be a good special tag for this case since it doesn't intrude on the existing tag namespace, a la Steve Cameron's .trunk/.parent/.base patch that needs to be ported forward and committed someday. Well I would like to take a look at this patch but I cannot find it, neither in the archives nor with google. Does anybody have an old copy lying around? Regards, Frank ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | If your second part, above, were abstracted out such that the new | revision-1 tag could be used anywhere CVS accepts two revision | options (basically, diff update/commit -j), then this format | could also be used to concisely back out a commit or to merge a | specific commit to a new location. | | It's possible that something like `.previous' would be a good | special tag for this case since it doesn't intrude on the | existing tag namespace, a la Steve Cameron's .trunk/.parent/.base | patch that needs to be ported forward and committed someday. | | | Well I would like to take a look at this patch but I cannot find | it, neither in the archives nor with google. Does anybody have an | old copy lying around? Steve's page has been down for awhile, I think, but I found a reference in the WayBack machine: http://web.archive.org/web/20011004170734/http://www.geocities.com/dotslashstar/branch_patch.html The most recent version of the patch I could find, also from the wayback machine, is here: http://web.archive.org/web/20011004195552/www.geocities.com/dotslashstar/patch.08.29.2001.txt I was just glancing at that patch and I think I can implement what Steve did much more succinctly, so I'm going to take a shot at it. The most important thing for your patch is probably to use the naming scheme: `.XXX'. Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCHe5MLD1OTBfyMaQRAvesAKDXzSlwBL/Ij0A+ia5O2JaOqGv+SgCdFKp/ V67SS63X8K8hc/7zHz/YPnw= =ep8G -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer wrote: | I have added support for the commitid in about the same manner as | it is implemented in cvsnt, so this shouldn't be a compatibility | issue. However, the commitid is as well added to the 1.1 and | 1.1.1.1 revisions at the initial import. | | Here goes the patch: This patch looks pretty good at first glance, but it needs test cases in src/sanity.sh and documentation in doc/RCSFILES and doc/cvs.texinfo before it may be committed. Please see the HACKING file from the source distribution for more on the CVS patch acceptance policy, and the TESTS file on how to write sanity.sh test cases. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCHfq+LD1OTBfyMaQRAtRjAKCM16E5OuXfdiyJU3Jtnq77r8+WRQCdGrl3 bv1FEU9/J7oYvZAWbKnCtf8= =6ROx -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
On Wednesday 23 February 2005 00:31, Derek Price wrote:
Frank Hemer wrote:
| In response to an old thread/message from dec 04,
| (http://lists.gnu.org/archive/html/bug-cvs/2004-12/msg00150.html) I
| would like to add some suggestions:
|
| The cvsnt commitid feature for the log cmd is a very neet feature
| because it allows to collect all versions that belong to a single
| commit.
Yes, this would be nice.
I have added support for the commitid in about the same manner as it is
implemented in cvsnt, so this shouldn't be a compatibility issue. However,
the commitid is as well added to the 1.1 and 1.1.1.1 revisions at the initial
import.
Here goes the patch:
Index: src/cvs.h
===
RCS file: /cvs/ccvs/src/cvs.h,v
retrieving revision 1.328
diff -u -r1.328 cvs.h
--- src/cvs.h 23 Feb 2005 19:59:49 - 1.328
+++ src/cvs.h 24 Feb 2005 15:35:05 -
@@ -896,3 +896,6 @@
void cvs_flusherr (void);
void cvs_flushout (void);
void cvs_output_tagged (const char *, const char *);
+
+#define GLOBAL_SESSION_ID_LENGTH 64
+extern char global_session_id[GLOBAL_SESSION_ID_LENGTH];
Index: src/import.c
===
RCS file: /cvs/ccvs/src/import.c,v
retrieving revision 1.165
diff -u -r1.165 import.c
--- src/import.c21 Feb 2005 18:51:58 - 1.165
+++ src/import.c24 Feb 2005 15:35:06 -
@@ -1275,6 +1275,9 @@
if (fprintf (fprcs, next%s;\012, add_vhead) 0)
goto write_error;
+ if (fprintf (fprcs, commitid%s;\012, global_session_id) 0)
+ goto write_error;
+
#ifdef PRESERVE_PERMISSIONS_SUPPORT
/* Store initial permissions if necessary. */
if (config-preserve_perms)
@@ -1306,6 +1309,9 @@
if (fprintf (fprcs, next ;\012) 0)
goto write_error;
+ if (fprintf (fprcs, commitid%s;\012, global_session_id) 0)
+ goto write_error;
+
#ifdef PRESERVE_PERMISSIONS_SUPPORT
/* Store initial permissions if necessary. */
if (config-preserve_perms)
@@ -1322,7 +1328,8 @@
fprintf (fprcs, date %s; author %s; state Exp;\012,
altdate1, author) 0 ||
fprintf (fprcs, branches ;\012) 0 ||
- fprintf (fprcs, next ;\012) 0)
+ fprintf (fprcs, next ;\012) 0 ||
+ fprintf (fprcs, commitid%s;\012, global_session_id)
0)
goto write_error;
#ifdef PRESERVE_PERMISSIONS_SUPPORT
Index: src/log.c
===
RCS file: /cvs/ccvs/src/log.c,v
retrieving revision 1.99
diff -u -r1.99 log.c
--- src/log.c 1 Feb 2005 21:43:48 - 1.99
+++ src/log.c 24 Feb 2005 15:35:06 -
@@ -1635,6 +1635,16 @@
cvs_output_tagged (text, -);
cvs_output_tagged (text, pdel-data);
}
+
+cvs_output_tagged (text, ;);
+p = findnode(ver-other_delta,commitid);
+if(p p-data)
+{
+cvs_output_tagged (text, commitid: );
+ cvs_output_tagged (text, p-data);
+ cvs_output_tagged (text, ;);
+}
+
cvs_output_tagged (newline, NULL);
if (ver-branches != NULL)
Index: src/main.c
===
RCS file: /cvs/ccvs/src/main.c,v
retrieving revision 1.239
diff -u -r1.239 main.c
--- src/main.c 23 Feb 2005 19:59:49 - 1.239
+++ src/main.c 24 Feb 2005 15:35:10 -
@@ -25,6 +25,8 @@
const char *program_path;
const char *cvs_cmd_name;
+char global_session_id[GLOBAL_SESSION_ID_LENGTH]; /* Random session ID */
+
char *hostname;
#ifdef SERVER_SUPPORT
char *server_hostname;
@@ -678,6 +680,12 @@
cause intermittent sandbox corruption.);
}
+/* Calculate the cvs global session ID */
+
+
sprintf(global_session_id,%x%08lx%04x,(int)getpid(),(long)time(NULL),rand()0x);
+
+TRACE(TRACE_FUNCTION,Session ID is %s,global_session_id);
+
/* Look up the command name. */
cvs_cmd_name = argv[0];
Index: src/rcs.c
===
RCS file: /cvs/ccvs/src/rcs.c,v
retrieving revision 1.329
diff -u -r1.329 rcs.c
--- src/rcs.c 23 Feb 2005 01:24:28 - 1.329
+++ src/rcs.c 24 Feb 2005 15:35:11 -
@@ -4954,6 +4954,7 @@
#ifdef PRESERVE_PERMISSIONS_SUPPORT
struct stat sb;
#endif
+Node *np;
commitpt = NULL;
@@ -5023,6 +5024,16 @@
else
delta-state = xstrdup (Exp);
+delta-other_delta = getlist();
+
+/* save the commit ID */
+np = getnode();
+np-type = RCSFIELD;
+np-key = xstrdup (commitid);
+np-data = xstrdup(global_session_id);
+addnode (delta-other_delta, np);
+
+
#ifdef PRESERVE_PERMISSIONS_SUPPORT
/* If permissions should be preserved on this project, then
save the permission info. */
Index: src/status.c
Re: Feature request/ideas
I was just glancing at that patch and I think I can implement what Steve did much more succinctly, so I'm going to take a shot at it. The most important thing for your patch is probably to use the naming scheme: `.XXX'. So I'll wait for your commit then. Regards Frank ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Feature request/ideas
In response to an old thread/message from dec 04, (http://lists.gnu.org/archive/html/bug-cvs/2004-12/msg00150.html) I would like to add some suggestions: The cvsnt commitid feature for the log cmd is a very neet feature because it allows to collect all versions that belong to a single commit. Another idea is a diff extension: Set to a specific revision (using the diff -r option), I would like to compare this revision against its direct parent. Any comments? Regards Frank ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
