Re: GNULib save-cwd.c on Windows Visual Studio 6.0
Here's a patch that should restore the ability of save-cwd to work on systems without the fchdir function. Would you please see if this is sufficient? If so, I'll check it in to gnulib (with an AC_CHECK_FUNCS(fchdir) in save-cwd.m4). Index: save-cwd.c === RCS file: /fetish/cu/lib/save-cwd.c,v retrieving revision 1.24 diff -u -p -r1.24 save-cwd.c --- save-cwd.c 20 Jan 2005 22:17:26 - 1.24 +++ save-cwd.c 9 Mar 2005 07:49:19 - @@ -44,6 +44,18 @@ #include chdir-long.h #include xgetcwd.h +/* On systems without the fchdir function (WOE), pretend that open + always returns -1 so that save_cwd resorts to using xgetcwd. + Since chdir_long requires fchdir, use chdir instead. */ +#if !HAVE_FCHDIR +# undef open +# define open(File, Flags) -1 +# undef fchdir +# define fchdir(Fd) abort () +# undef chdir_long +# define chdir_long(Dir) chdir (Dir) +#endif + /* Record the location of the current working directory in CWD so that the program may change to other directories and later use restore_cwd to return to the recorded location. This function may allocate ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Defect with Diff3 utility
Hi, (B (B (B (BCould anyone shed some light on this peculiarity of the diff3 utility? (B (B (B (BHere$B!G(Js the example OLDFile is as below, (B (B (B (B#ENGLISH Resource File (B (B (B (B#DoNotTranslate (B (BL6_WINDOWS = OK|O (B (B# fail to enable path. (B (Bset_pathEnabled_failed = Failed to enable the path. (B (B# fail to set preferred path. (B (Bset_preferredPath_failed = Failed to set preferred path. (B (Bset_primaryPath_failed = Failed to set primary path. (B (B# fail to purge disk (B (Bset_purgeDisk_failed = Failed to purge disks. (B (B# set Array status failed. (B (Bset_arrayStatus_failed = Failed to set array status. (B (B (B (B# please wait message (B (Bmsg_wait_for_system_update = The system is currently too busy to update the (Bdevice status. Please try the operation later. (B (B (B (B# hard_disk_name (B (Bhard_disk_name=Harddisk (B (B (B (B#Top Menu Item that displays short cut. In Japanese, Korea... , add (P) at the (Bend. (B (Btop_path_menu = Path|P (B (B (B (B (B (BNew file is as below, (B (B (B (B#ENGLISH Resource File (B (B (B (B#DoNotTranslate (B (BL6_WINDOWS = OK|O (B (B#EndDoNotTranslate (B (B (B (B# labels for the DMP client extension (B (BNONE_ID = None (B (BACTIVE_ACTIVE_ID = Active/Active|A (B (BACTIVE_PASSIVE_ID = Active/Passive|P (B (BNAME_ID = Array Name: (B (BOK_ID = OK|O (B (B# fail to enable path. (B (Bset_pathEnabled_failed = Failed to enable the path. (B (B# fail to set preferred path. (B (Bset_preferredPath_failed = Failed to set preferred path. (B (Bset_primaryPath_failed = Failed to set primary path. (B (B# fail to purge disk (B (Bset_purgeDisk_failed = Failed to purge disks. (B (B# set Array status failed. (B (Bset_arrayStatus_failed = Failed to set array status. (B (B (B (B# please wait message (B (Bmsg_wait_for_system_update = The system is currently too busy to update the (Bdevice status. Please try the operation later. (B (B (B (B# hard_disk_name (B (Bhard_disk_name=Harddisk (B (B (B (B#Top Menu Item that displays short cut. In Japanese, Korea... , add (P) at the (Bend. (B (Btop_path_menu = Path|P (B (B (B (BARRAY_GROUP_NODES = Arrays (B (BNote there is only a single CR at the end of this file and this (Bstatement is not part of the file. (B (B (B (BYOURFILE is (B (B (B (B#JAPANESE Resource File (B (B (B (B#DoNotTranslate (B (BL6_WINDOWS = OK|O (B (B#EndDoNotTranslate (B (B (B (B# labels for the DMP client extension (B (BNONE_ID = $B$J$7(J (B (BACTIVE_ACTIVE_ID = $B%"%/%F%#%V!_%"%/%F%#%V(J|A (B (BACTIVE_PASSIVE_ID = $B%"%/%F%#%V!_%Q%C%7%V(J|P (B (BNAME_ID = $B%"%l%$L>(J: (B (BOK_ID = $BN;2r(J|O (B (B# fail to enable path. (B (Bset_pathEnabled_failed = $B%Q%9$NM-8z2=$K<:GT$7$^$7$?!#(J (B (B# fail to set preferred path. (B (Bset_preferredPath_failed = [EMAIL PROTECTED]@_Dj$K:GT$7$^$7$?!#(J (B (Bset_primaryPath_failed = $B%W%i%$%^%j(J [EMAIL PROTECTED];$s$G$7$?!#(J (B (B# fail to purge disk (B (Bset_purgeDisk_failed = $B%G%#%9%/$N>C5n$K<:GT$7$^$7$?!#(J (B (B# set Array status failed. (B (Bset_arrayStatus_failed = $B%"[EMAIL PROTECTED]<:GT$7$^$7$?!#(J (B (B (B (B# please wait message (B (Bmsg_wait_for_system_update = $B%7%9%F%`$,%S%8!<$J$?$a!"%G%P%$%9>uBV$r99?7$G$-$^$;$s$G$7$?!#$"$H$G$b$&0lEY
intermittenly happens when using commit
Some times when I do a CVS commit, text like the following is appended to the bottom of the file that I have committed: ** date: Friday, February 18, 19105 @ 14:44 author: username Update of /data/implementation/cvs/operational/bin In directory system:/data/system1/username/bin Modified Files: emacs-init.el ops-env Log Message: This does not happen every time. When it does happen, I edit it out and recommit; but it is annoying. This started happening right after the aussie-wizard replacement on S systems. As part if that project, Otto installed a new version (1.12.9) of CVS. Since then, I have used both the new and the old (1.11) versions of CVS; and have seen this problem with similar frequency in both versions. -- Romeo Gourgue Jr Network/UNIX Administrator Space Telescope of Science Institute 410-338-2615 ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [bug-gnulib] GNULIB wait-process module.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Haible wrote: | Thanks for explaining. Your objective is clear now. | | But how would you want this to work on Woe32? I assume that you | would want this debugging feature also on Windows. How do you | implement it there? Actually, the CVS server isn't completely portable to WOE32, so this code never runs there anyhow. Even if we do reach a point where the server runs on WOE32 again, the fact that WCOREDUMP always evaluates to false on WOE32 and does us no good makes me want the data dir to be left behind on UNIX no less. If the server does get ported completely, then perhaps the porter will have some ideas about how to get the same effect there. | The change I'm proposing is simple. I've attached a patch. | | | I'm opposed to this change because I don't see how it can be made | to work on Windows. In other words, it makes unportable | assumptions. My patch is based on no new assumptions. wait_subprocess() was already calling WIFSIGNALED WTERMSIG on the results of a wait. There is code at the top of the file defining these macros to values under WOE32 that I assume do something sensible there. All my patch does is, when WIFSIGNALED returned true, then set the input var to the terminating signal via WTERMSIG, which is already being called in the same circumstances. The caller can then process this value. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCLvx8LD1OTBfyMaQRAku/AJ9RiEZBfAh7G5sHW+g/nuN3VfNl0wCgrox2 6epQNVF1oC1zRT7Sj8RaygU= =jQYF -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: GNULib save-cwd.c on Windows Visual Studio 6.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jim,
From: Jim Meyering [mailto:[EMAIL PROTECTED]
This is not about Microsoft per se, but simply about
the lack of fchdir (or POSIX support in general) in WOE.
I agree let's not enumerate Microsoft's flaws as we would never
finish. :)
I suppose it's a long shot, but...
is there a way, in WOE/MSVC, to emulate fchdir's behavior?
I think not. My research on http://msdn.microsoft.com site came
up with no hint of a method to translate an open file / directory
handle into a path name.
I.e., given a file descriptor that is the result of opening a
directory, can you obtain an absolute path name of that directory?
Worse, if C:\work is a directory attempts to use the Visual C 6.0
open function with _O_RDONLY argument to open . or C:\work
will both return -1 value i.e. error. Sample program follows.
Conrad
#include stdio.h
#include io.h
#include fcntl.h
static int opendir( char *name )
{
int fd;
fd = open( name, _O_RDONLY );
printf( open %s = %d\n, name, fd );
close( fd );
return fd;
}
int main(int argc, char* argv[])
{
int fd;
printf(Hello World!\n);
fd = opendir( test.txt );
fd = opendir( . );
fd = opendir( C:\\work );
return 0;
}
-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4
iQA/AwUBQi8GwLNM28ubzTo9EQJxHwCg4H3VBV4ftjY6Jau9DuleH/0mvykAoLee
EKxRsykxCHYpu0r1VRvKe6aq
=RI6I
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: GNULib save-cwd.c on Windows Visual Studio 6.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jim, From: Jim Meyering [mailto:[EMAIL PROTECTED] Here's a patch that should restore the ability of save-cwd to work on systems without the fchdir function. Would you please see if this is sufficient? If so, I'll check it in to gnulib (with an AC_CHECK_FUNCS(fchdir) in save-cwd.m4). The patch as submitted does not compile. This line fails: return fchdir (cwd-desc); The patch at message end does compile and the build completes. Conrad Index: save-cwd.c === RCS file: /cvs/ccvs/lib/save-cwd.c,v retrieving revision 1.6 diff -u -p -r1.6 save-cwd.c - --- save-cwd.c 1 Mar 2005 18:15:42 - 1.6 +++ save-cwd.c 9 Mar 2005 14:50:43 - @@ -44,6 +44,18 @@ #include chdir-long.h #include xgetcwd.h +/* On systems without the fchdir function (WOE), pretend that open + always returns -1 so that save_cwd resorts to using xgetcwd. + Since chdir_long requires fchdir, use chdir instead. */ +#if !HAVE_FCHDIR +# undef open +# define open(File, Flags) -1 +# undef fchdir +# define fchdir(Fd) ( abort (), -1 ) +# undef chdir_long +# define chdir_long(Dir) chdir (Dir) +#endif + /* Record the location of the current working directory in CWD so that the program may change to other directories and later use restore_cwd to return to the recorded location. This function may allocate -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQi8OqrNM28ubzTo9EQKCQACglWgegbLzUqZdLaxd+HC+ls9Jv7oAn1J5 0z2tXUL54UlQZECFNzsG4PuC =7E/O -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: | 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: this happens sometimes
Romeo Gourgue wrote two variations on the following: Some times when I do a CVS commit, text like the following is appended to the bottom of the file that I have committed: ** date: Friday, February 18, 19105 @ 14:44 author: username Update of /data/implementation/cvs/operational/bin In directory system:/data/frodo1/aroman/bin Modified Files: emacs-init.el ops-env Log Message: This does not happen every time. When it does happen, I edit it out and recommit; but it is annoying. This started happening right after the aussie-wizard replacement on SOGS. As part if that project, Otto installed a new version (1.12.9) of CVS. Since then, I have used both the new and the old (1.11) versions of CVS; and have seen this problem with similar frequency in both versions. First of all, this is not a chat group, you cannot expect an instant response. If your second post was because of a suspected error in sending, then you should state that in your message. Check your email notification script. This looks like the text that would normally be sent via email to anyone watching the directory. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ 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
proxy environment variables
Hi, the 1.12.x series contains the http tunnel web proxy patch. This patch originaly allowed to specify the proxy and proxyport using environment variables (PSERVER_PROXY) in the form of 'my.proxy.server[:PORT]', in addition to specifying it in the CVSROOT. This has the advantage of not having to change an existing CVSROOT if the setup of a proxy server has changed, or was added later. I would like to see this behavior in the current 1.12 tree too, because it allows to store and manage the proxy setup separate from the CVSROOT. What do you think? 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: windows-NT/mkconfig.pl windows-NT/fix-msvc-mak.pl change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Derek, I'm slow to understand the goal. I'm coming to the conclusion what you're trying is eliminate the difference between: *** config.h.in, generated by mkconfig: as opposed to: *** config.h.in, generated by mkconfig.pl: and if that's the case then I believe it's not a Windows or UNIX issue. I propose it's an operation difference issue as follows: The UNIX make process generates intermediates: fix-msvc-mak mkconfig of which mkconfig is used later in the build and fix-msvc-mak is built but not used in the build. Previously I wasn't aware of the existence of the intermediates on UNIX and of course they don't exist on Windows. The commands I ran on both Windows and UNIX are: cd ccvs perl windows-NT/fix-msvc-mak.pl cd windows-NT perl mkconfig.pl cd .. which in the case of mkconfig will generate: *** config.h.in, generated by mkconfig.pl: when run on either Windows and UNIX. I believe no patch is required. I will correct my process now that I understand why the intermediates exist. Conrad -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQi9JjrNM28ubzTo9EQIKhgCglpDGRupS5gwAKZD0wxVqMKdlzA4An2rk Lv3ZH3gShpt7zrOIkbvhB0Vw =sbX4 -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: | 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: windows-NT/mkconfig.pl windows-NT/fix-msvc-mak.pl change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: | Previously I wasn't aware of the existence of the intermediates on | UNIX and of course they don't exist on Windows. The commands I ran | on both Windows and UNIX are: | | cd ccvs perl windows-NT/fix-msvc-mak.pl cd windows-NT perl | mkconfig.pl cd .. | | which in the case of mkconfig will generate: | | *** config.h.in, generated by mkconfig.pl: | | when run on either Windows and UNIX. | | I believe no patch is required. I will correct my process now that | I understand why the intermediates exist. Yeah, but the intermediates are not necessary. My patch calls, similarly, ~perl mkconfig.pl where a simple ~./mkconfig used to be called. Since there is no mkconfig file distributed or checked in, my patch should sync what we are generating. It also has the advantage or simplifying by removing the unneeded intermediates. Regardless, I think you have answered my question. I will commit the change and your previous build process should still suffice. Have you thought about putting the `perl mkconfig.pl' and `perl fix-msvc-mak.pl' calls into the MSVC build files (is that even possible with fix-msvc-mak.pl?)? It's always nice to encode our build knowledge into automation when possible. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCL1KVLD1OTBfyMaQRAlmeAKCi0dQecn8Q9lfHndlIm2rt+fFDTACgnbtd Az/X4epxDLpsm0h7OworT74= =ZBf6 -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: 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: GNULib save-cwd.c on Windows Visual Studio 6.0
Conrad T. Pino [EMAIL PROTECTED] wrote: ... Would you please see if this is sufficient? If so, I'll check it in to gnulib (with an AC_CHECK_FUNCS(fchdir) in save-cwd.m4). The patch as submitted does not compile. This line fails: return fchdir (cwd-desc); The patch at message end does compile and the build completes. Thanks. I've checked that in. ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: GNULib save-cwd.c on Windows Visual Studio 6.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jim, From: Jim Meyering [mailto:[EMAIL PROTECTED] Conrad T. Pino [EMAIL PROTECTED] wrote: ... Would you please see if this is sufficient? If so, I'll check it in to gnulib (with an AC_CHECK_FUNCS(fchdir) in save-cwd.m4). The patch as submitted does not compile. This line fails: return fchdir (cwd-desc); The patch at message end does compile and the build completes. Thanks. I've checked that in. I've seen the lib/save-cwd.c change in GULLib CVS on Savannah but I didn't see the AC_CHECK_FUNCS(fchdir) in save-cwd.m4 change. Conrad -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQi+5KrNM28ubzTo9EQLWKwCgp1C8kpucYC92QRaGblHAp5+z0xIAniOF WX8BVodiTSIchNoDxIi4ZwT9 =Nwqu -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
