Re: Timestamp race avoidance in do_update()
BTW - on the subject of this sleep, I've found that it *greatly* improves the amount of time it takes a rather long script to run if I remove the sleep in the client. I know that's dangerous and stupid in the general case, but in my specific case it doesn't cause any harm. What I'm wondering is if we could change the "sleep(1); to be a usleep(200) in a while loop instead. This should trim 1/2 a second from each invocation of commit, on average, which can be quite a lot when you're talking about several thousand files with dozens of revisions for each... [EMAIL PROTECTED] (Larry Jones) writes: > Brad Chisholm writes: > > > > Just to make sure I understand, CVS is sleeping to ensure that any post-CVS > > process which might modify the file must also change the timestamp. This > > is necessary, because the CVS client relies on the timestamp to determine > > whether a file has been modified. (i.e. if the current timestamp of the > > file matches the timestamp stored in the Entries file, then the client > > will consider the file unchanged, even if the contents have actually changed). > > Exactly. As I said in the thread you quoted, you should send all of the > file information first and then a single update command, not a separate > update command for each file. Also, the current development version no > longer sleeps when in server mode; it is up to the client to do it > instead. > > -Larry Jones > > Monopoly is more fun when you make your own Chance cards. -- Calvin > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Timestamp race avoidance in do_update()
[EMAIL PROTECTED] (Larry Jones) writes: > Laine Stump writes: > > > > What I'm wondering is if we could change the "sleep(1); to be a > > usleep(200) in a while loop instead. This should trim 1/2 a second > > from each invocation of commit, on average, which can be quite a lot > > when you're talking about several thousand files with dozens of > > revisions for each... > > Unfortunately, usleep() isn't portable. Okay, then how about nanosleep()? Here's what the nanosleep() manpage on NetBSD says about its portability: The nanosleep() function conforms to IEEE Std 1003.1b-1993 (``POSIX''). (This is "Realtime Extensions to Posix"). (The only standard that applies to usleep() is "X/Open Portability Guide Issue 4 Version 2 (XPG4.2), which doesn't sound nearly as impressive as something with POSIX in the name). Note that Windows doesn't even have sleep(). The "glue" stuff in the windowsNT directory implements a sleep(n) function which is a call to the Windows API Sleep(n*1000). (No, I don't know what the Honeywell Level 6 OS provides, or VMS or whatever. Unfortunately, the only machines I have access to these days are NetBSD, Linux, and Windoze). > Like I keep saying, the trick > (if you want to call it that) is to commit those several thousand files > with a single invocation of commit so you only pay the price once > instead of over and over and over. That would make for a *much* more complex and memory-intensive perl script (the script in question being one which converts VSS history to CVS history). Aside from the basic extra duty of keeping track of multiple files at once rather than cycling through a list, each commit for each file has a different log comment, so multiple commits *can't* be done with a single invocation of cvs. (I take that back - I suppose I could save all log comments, then go back and change them later with a long string of "cvs admin -m: " commands, but that makes the script even more complex and memory intensive, and we must remember that I'm a lazy programmer, who would rather change one sleep to nanosleep() than to write a ton of confusing perl ;-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: how to connect to a repository?
"vidhya d" <[EMAIL PROTECTED]> writes: > i am facing a problem in cvs. it is that i need to connect to > windows 95 from solaris to access a repository > there .how to > connect to windows 95 /access the repository there from solaris? You don't. Win95 cannot act as a CVS server; only Unix (and WinNT, using the patched version available from the palce listed in the FAQ somewhere) machines can be CVS servers. Move the repository to the Solaris machine, and configure both the Win95 and Solaris clients to use the Solaris machine as server. BTW - please check the datea on your workstation - it is set to Feb 15, 2000, which makes all your messages sort to the top of most people's inboxes. It was pure coincidence that I scrolled up to the top and saw your message at all. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Timestamp race avoidance in do_update()
Brad Chisholm <[EMAIL PROTECTED]> writes: > On Wed, Feb 14, 2001 at 09:58:46PM -0500, Derek R. Price wrote: > > > > Well, it didn't seem very hard to do, so I had configure search for > > nanosleep, usleep, and select in that order, then use them in the same > > order of preference, falling back on sleep as a last resort. It speeds up > > 'make check' noticeably. > > > > Checked in. > > Just curious, but will a 20 ms wait be sufficient to prevent timestamp races? > It appears the times saved in the Entries file have a granularity of 1 sec. Did you look at the code? The 20ms delay is in a loop that repeats until the value returned from time() changes. the value returned from time() changes once each second (ie it has a granularity of 1 sec), so there is no problem. All that this change does is eliminate a lot of extra wait *after* the system time had already changed. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Automatic tagging using revision log message
"David L. Martin" <[EMAIL PROTECTED]> writes: > I appreciate the direction you're heading with this effort. What I > can contribute is a set of CVS loginfo trigger scripts which provide > automatic tagging of the revision being checked in based on an SCR > number indicated in the revision log comment (specificaly, using the > autotag.pl perl script). It would be wonderful to have this integrated into the cvssupport package at: http://www.sourceforge.net/projects/cvssupport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sticky directory bit vs. loginfo chgrp
Although I remember doing this on a Solaris server in the past (getting new directories and files to be in the proper group, with proper permissions, by setting the setgid bit on the cvsroot directory), I've been trying to make this work on NetBSD and it doesn't. For example: # ls -ld . drwxrwsr-x 9 root staff 512 Feb 22 12:34 ./ # mkdir test # ls -ld test drwxr-xr-x 2 laine staff 512 Feb 22 12:35 test/ What am I missing? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: What's in repository
[EMAIL PROTECTED] (Larry Jones) writes: > [EMAIL PROTECTED] writes: > > > > Is there a way to: > > 1. "Browse" the repository, i.e. the equivalent of doing a "ls" of a > > source directory? > > There's checkout -c, but that just lists the modules file, not actual > directory contents. And there is the wonderful "cvsls" hack (originally by Eugue Kramer, according to the file in tkcvs where I just lifted this): cvs rdiff -s -D 01/01/1971 -r $rev $mcode where $rev is the branch you want to look at, and $mcode is the toplevel module. Of course, you need to know the name of the toplevel momdule first (which hopefully will be listed in the modules file, and thereby in cvs co -c). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sticky directory bit vs. loginfo chgrp
[EMAIL PROTECTED] (Larry Jones) writes: > sgid only affects the group, not the permissions. (And it's the way BSD > traditionally behaves, so you probably don't need it on NetBSD.) Ah so. I had just assumed that doing setgid would put the same permission in created files and subdirectories. In particular, it's very useful to have g+w turned on. So what's the best way to make sure that every new file and directory in the repository has g+w? (Aside from telling everyone to set their umask to 002, that is). Without that, any attempts by other users to even checkout from (much less commit changes to) a new directory created by someone else end in failure. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sticky directory bit vs. loginfo chgrp
"Derek R. Price" <[EMAIL PROTECTED]> writes: > Laine Stump wrote: > > > So what's the best way to make sure that every new file and directory > > in the repository has g+w? (Aside from telling everyone to set their > > What happens if you set UMASK from inetd? Nevermind. I seem to be imagining problems where they don't exist. I just tried it out again and this is what happens: * if a directory is created with "cvs add dirname" it will be created with the group of the parent (in the repository), and group write permission turned on, regardless of the user's umask. * if a file is created with "cvs add file; cvs commit", it will be created with the group of the parent, and mode 444. However, since the directory that contains it has g+w, cvs can get around this when another user attempts to modify it by doing the equivalent of: cp file,v temp rm file,v mv temp file,v (I don't know if that's what CVS does, but it works and proves that proper operation is possible) So, now that I understand what's going on, there is no problem ;-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Adding new files to branch puts them in the Attic?
"Dennis Jones" <[EMAIL PROTECTED]> writes: > I am working on a branch in which I am doing some side development. If > everything goes as planned, then this branch will eventually get merged into > the main trunk. The wierd thing is that when I add new files or directories > to this branch, all the new files end up in Attic subdirectories in the > repository. Why is that? Shouldn't files only go into the Attic when they > are removed, not added? Files go into the Attic when they don't exist on the trunk. If a file is added on a branch, it doesn't exist on the trunk, so the ,v file goes in the Attic. When you want to merge your work into the trunk, you'll need to add those new files on the trunk, after which the ,v file will be moved out of the Attic. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [log aborted]: linefeed expected in file.c,v
Rob Helmer <[EMAIL PROTECTED]> writes: > Just so I understand the problem, is it ok to mount a sandbox > over NFS or samba, work on it, ssh to the sandbox ( let's > say it's a home directory ) and do cvs commit there? As Dereck confirms, the main problem with CVS and remote filesystems is when the CVS repository itself is mounted from a remote location to a local disk. A remote work directory isn't nearly as dangerous, and (as you say) is quite useful. There is one potential problem though - if you have a work directory on a Unix box and you do some modifications (eg cvs operations, editing files) on the Unix box, and some on a Windows box (eg compiling, more editing), you'll find that the Unix and Windows machines sometimes don't agree on the contents of the files. This is because Samba implements "oppurtunistic" locks on files - locks which a client can create, and which are then broken by the server when someone else modifies the file in the area that was locked. The problem is that the Samba server, being a userland daemon, can properly (and efficiently) recognize and notify when another Samba client does something that necessitates breaking a lock, but it *can't* recognize when something other than Samba (eg, another NFS client, or an Emacs running locally on the Unix box) necessitates breaking the lock; the result is that teh client machine thinks that its cached data is valid when it isn't. Irix has implemented kernel hooks to allow the filesystem to directly notify Samba when a lock must be broken, but no other OS has done it yet. In the meantime, you need to be careful about this, or set the registry as described in: docs/textdocs/File-Cacheing.txt in the Samba source distribution (which also contains a much better description of the problem). Having said that, I have been using cvs + samba + windows + unix in exactly this way for several years now, and have never suffered any terrible tragedy. As long as you know the conditions you're working under, the problems can be worked around. (P.S. - another potential problem is that is you use CVS on the Unix box, all the files will be checked out with just LF at the end of each line. Some Windows utilities handle this just fine (eg, the MSVC++ compiler), but others don't (eg, notepad, and the editor in MS Visual Studio). I just do most all of my editing with Emacs on an X display from the Unix box. Someone recently pointed me to a Visual Studio AddIn that removes CRs from all files as Visual Studio saves them. It's at: http://codeguru.earthweb.com/devstudio_macros/stripem.shtml ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Bulk-Add
Richard Cobbe <[EMAIL PROTECTED]> writes: > > If there is only the import method to handle huge directory-trees, > > then the second question is answered as well. > > The situation is: > > - Someone adds some directories and files on the working directory. > > - He has no idea of CVS. > > - After some days he comes to me to add/commit his new/changed files > > and folders to the repository. > > - He cannot remamber which files and folders he created (sic!). > > - Now I would like to add all new files and folders (lots of them). > > Yuk. That, I'm afraid, is a situation I don't really know how to handle. > Perhaps someone else on the list can contribute? It seems like shell scripts are becoming a lost art... Okay, assuming that the work directory this other person is using began its life by being checked out from CVS, just do something like this from the toplevel directory: cvs update | grep '^\?' | cut -d" " -f2-100 | \ while read f do cvs add "$f" done You may need to do this a few times (once for each level of new directory created), because I haven't made it recursive. The first line prints a list of all files that cvs thinks need to be added (anything that isn't already in the repository, and which doesn't match any of the patterns in .cvsignore, or the default cvsignore list (see the documentation, including the -I option). On the other hand, if the work directory the other person is using *didn't* begin its life being checked out from CVS, then shame on you! ;-) You can get around that by checking out a new work directory and merging in the other person's changes by hand, but that's a lot of extra work for no gain. Finally, if your client is on Windows, don't *completely* despair - install the CygWin tools from www.cygwin.com - it includes a copy of the bash shell, which makes running Windows almost tolerable (and can run the simple script above). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: ignoring ID]
"Trott, David" <[EMAIL PROTECTED]> writes: > For various reasons (such as external vendors only releasing binaries) we > use CVS to control .class files, other people may wish to store other binary > files in CVS. > > It may cause a problem for some people if these binary files were added to > the ignore list. That can be said for every type of file already on the ignore list as well. That's what the -I ! option is for. I think the idea is to get things on there that are normally generated as a part of the build process; if you've got things that aren't built locally but are on the list, then you need to be aware of it and take appropriate action. (P.S. - maybe there should be a "-I-" counterpart to "-I", which would mean "*Don't* ignore files matching the following pattern". This way somebody who wanted to "pay attention to" a single file type could just do, eg "-I- *.class", rather than "-I ! -I *.lib -I *.o -I *~ " > David > > "Larry Jones" <[EMAIL PROTECTED]> wrote in message > news:<[EMAIL PROTECTED]>... > > Derek R. Price writes: > > > > > > Is there a policy on adding file names to the default ignore list? > > > > Not really, and it does seem to be a bit dated. In addition to ID as > > suggested by Assar Westerlund, Pavel Roskin submitted a patch on 30 Jan > > 2001 that proposed adding: > > > > .depsAutomake > > .depend Linux, MC and possibly others > > .libsLibtool > > *.gz Gzip > > *.bz2Bzip2 > > *.flags Linux > > *.la Libtool > > *.lo Libtool > > > > and I'd also suggest adding: > > > > *.libDOS/Windows library > > *.dllDOS/Windows dynamic load library > > *.sl HP-UX sharable library > > *.class Java binary > > *.backup Misc backup file > > *.dviTeX output > > *.info* GNU info file > > > > Perhaps a discussion on info-cvs is in order to see what people think > > about these or other additions? > > > > -Larry Jones ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Looking for *real* docs
You just listed all the things the "tool-makers" read. There is no uber-society of CVS-related tools writers who share their information using coded messages and secret handshakes. They all work it out by reading the manpages and manuals, looking at the output of commands, and lifting useful code from stuff already written by someone else. Also, when they have a specific question and can't figure out the answer themselves, they post that question to this list and usually end up with a reasonable answer. (Hint - it might help if you gave more specifics of why just using the CVS log command isn't enough for you). So, you're looking in the right places, you just haven't looked long enough, or tried hard enough, yet. ;-) Chris <[EMAIL PROTECTED]> writes: > I'm trying to write some code to allow you to browse a > repository. Crucial to this is thorough documentation of how to query > the repository for name & message information (through using 'log', I > guess), as well as documentation for the output of such commands, so I > can parse it. I've read man pages for rcs, rlog, and cvs, along with > additional online material including the Perdeqvist (sp) thingee, and > I can't find anything, or even a reference to what I'm looking for. > > There are several add-on tools that do this, and I could plow through > their source if need be, but I'd rather not - I'd rather read what the > tool-makers read, whatever that is. > > Any ideas? > Chris > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Controlling revision (version number)
Somewhere else in the CVS documentation you will find a bit that tells you that the revision numbers of files are intended for internal CVS use only, and that it is a bad idea to attempt to force them into some particular organization. On top of that, the revision numbers are for individual files, not for entire projects. You were on the right track with tags - you should just ignore the revision numbers, and make tags when you reach some milestone (such as release 2.4.4). Since CVS requires that tags start with a letter and not containing any "." characters, just put an R at the front, and replace all the "." with "_", is "R2_4_4". Jean Tourrilhes <[EMAIL PROTECTED]> writes: > Hi, > > (I'm not on the mailing list) > > I've recently put a project that I was maintaining into a CVS > repository (as part of a bigger project). CVS is driving me nuts with > the revision numbers. The result is that all version numbers in the > CVS repository are all over the place. Yuck ! > > When I started, my project was a revision 2.4.3 (my own > revision numbers). I did a cvs import, used the -b flag, and > everything was put in CVS at revision 2.4.3.1. Strange, but not too > bad. > I did a bit of hacking, added new files and co. I tried to do > a "cvs update ; cvs commit -r 2.4.4", but it refused : > cvs server: Up-to-date check failed for XXX (all my files) > So, I did a "cvs commit". And now, I have files with revision > 2.5, some with 2.4.3.1 and some other with 1.1. > Modified a few files to try, and now I have 2.6, 2.5, 2.4.3.1, > 1.2 and 1.1 revisions all mixed up :-( > Reread the man page, mention the "cvs tag" stuff that is > necessary for the -r option. So, I try a "cvs tag -b 2.4.4". It fail > saying that tag must start with a letter. Argh ! > > So please : could somebody be kind enough to tell me how to > control revision number with CVS ? I want to put all new and modified > files at revision 2.4.4, which is what it should be. Why does it have > to be so difficult ? > > Thanks in advance... > > Jean > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: info without working copy
[EMAIL PROTECTED] (Larry Jones) writes: > Largent, Jim writes: > > > > Is there some trick to getting information similar to cvs log without a > > working copy? > > Not that I know of. There should be an rlog command to do that, but > it's never been implemented. (There used to be an rlog command that > did something completely different, but it's been deprecated for a long > time now, so if anyone is looking for a project to do) And whoever decides to do that, can also implement an "rannotate" command. Pretty please? ;-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Revision numbers
Szabó Tamás <[EMAIL PROTECTED]> writes: > I wondering when will a revision number of form n.m change to the form > n+1.1 ? That will only happen if you manually force the revision number in a commit (I forget if this is even an option in cvs - the only time I've ever actually done it is with RCS, which does allow specifying the revision). In general it's best to let CVS decide which numerical revision number to use, and make a symbolic tag for places you want to reference later. > I guess it must be at least one case when m reaches the maximum > number of datatype on which is stored.(32 bits?) I've never looked at the code to determine that, but it's highly unlikely that anyone will ever make 4 billion revisions of the same file ;-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
I'm glad this message came by again - I just did an import and saw the that the behavior described by Larry below did not occur. Nothing is marked for deletion by CVS either during the import or during execution of the suggested "merging checkout" afterwards. Actually, there are times when this behavior is *good*, since it allows me to import "partial code drops" from 3rd parties who just send me a few files for a quick bugfix, rather than a full release. In most cacses it would be nice, though... > [EMAIL PROTECTED] writes: > > > > If I am importing a vendor project for the second or subsequent times > > on the same vendor branch, how can I mark the files that no longer > > exist in the vendor projects as deleted on the vendor branch? > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Doing the merge that CVS suggests when there are conflicts (even if > there aren't any conflicts) will mark the appropriate files for > deletion. Committing the results of the merge will then delete them. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
[EMAIL PROTECTED] (Larry Jones) writes: > Laine Stump writes: > > > > I'm glad this message came by again - I just did an import and saw the > > that the behavior described by Larry below did not occur. Nothing is > > marked for deletion by CVS either during the import or during > > execution of the suggested "merging checkout" afterwards. > > The suggested merge command assumes that you won't import more than one > release per day -- if you do, you need to use the explicit release tags > for the merge rather than the "vendor" and "vendor:yesterday" that CVS > suggests. (CVS can't suggest that itself since it has no way to know > what release tag you used the last time.) This was the first import in about 6 months. All the differences in files, and new files, were merged correctly. However, your message had indicated that file deletions would also be marked when I did the merge; this was not the case. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Microsoft VSS => CVS
Dave Cridland <[EMAIL PROTECTED]> writes:
> Are there any patches or techniques for CVS similar to the sharing
> functionality in VSS?
You can do something similar to sharing *entire directories*, via
specifying lines in the file CVSROOT/modules (look up the "modules"
file under "CVS Administrative files" in the documentation).
There is no CVS equivalent to VSS' sharing of individual repository
files into multiple places in the work directory, though. Many people
will tell you that sharing files from the repository is bad anyway,
since it often makes it nearly impossible to fully test changes before
doing a commit ("checkin", for a VSS person). The unfortunate reality
is that it seems to get used by VSS people *a lot*. (As a matter of
fact, a reorganization to eliminate shares of single files is the one
thing that's still holding us back from converting :-( ).
The only suggestion I can give is to reorganize your source so that
any shares are done as entire directories (and try to make as few as
possible, since your modules file could otherwise get quite
messy). Look at this as an oppurtunity to give your source code that
well-deserved organizational overhaul you've been wanting to do for so
long! ;-)
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
[EMAIL PROTECTED] (Larry Jones) writes: > [ example of cvs import followed by merge auto-deleting files ] That's great, but your example doesn't use the tags normally suggested in the results of imports, eg "-j NET:yesterday -j NET" (which in this case wouldn't work anyway because it had been less than a day between imports, but that's beside the point). When I do *exactly* the command suggested by cvs import, no deletes are scheduled, even though it has been more than a day since my last import. (Yes, I just tried it again to double-check). Here's what you first said: [EMAIL PROTECTED] (Larry Jones) writes: > Doing the merge that CVS suggests when there are conflicts (even if > there aren't any conflicts) will mark the appropriate files for > deletion. Committing the results of the merge will then delete them. That still is incorrect - apparently this is only done if you specify exact tags in the command; it doesn't happen if you use branch tags and/or date specifications (yesterday, two days ago, etc) as the command suggested by cvs import (ie "the merge that CVS suggests") does. I'll leave it up to you to decide whether this is a bug in CVS, or you misspoke ;-) Anyway, I'm glad to know that there is a way to make it work, even if it doesn't work when I follow CVS' instructions. [EMAIL PROTECTED] (Larry Jones) writes: > Laine Stump writes: > > > > This was the first import in about 6 months. All the differences in > > files, and new files, were merged correctly. However, your message had > > indicated that file deletions would also be marked when I did the > > merge; this was not the case. > > bash-2.02$ echo file1 >file1 > bash-2.02$ echo file2 >file2 > bash-2.02$ cvs import -m first tst NET FIRST > N tst/file1 > N tst/file2 > > No conflicts created by this import > > bash-2.02$ rm file1 > bash-2.02$ echo file3 >file3 > bash-2.02$ cvs import -m second tst NET SECOND > N tst/file3 > U tst/file2 > > No conflicts created by this import > > bash-2.02$ cvs co -j FIRST -j SECOND tst > cvs checkout: Updating tst > U tst/file1 > ==> cvs checkout: scheduling tst/file1 for removal > U tst/file2 > U tst/file3 > bash-2.02$ cd tst > bash-2.02$ cvs ci -m merge > cvs commit: Examining . > ==> Removing file1; > ==> /public/CVS/tst/file1,v <-- file1 > ==> new revision: delete; previous revision: 1.1.1.1 > ==> done > > -Larry Jones > > I'm so disappointed. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Microsoft VSS => CVS
Jon Miner <[EMAIL PROTECTED]> writes: > * Laine Stump ([EMAIL PROTECTED]) [010321 15:48]: > > There is no CVS equivalent to VSS' sharing of individual repository > > files into multiple places in the work directory, though. > > Well, not natively in CVS, but if you're running it on a server that > supports _symlinks_, you can approxmate that behavior, somewhat.. Just > symlink the actual repository files to multiple places, works rather > well. ...until one day when the symlinked file magically becomes corrupted. CVS sets locks on a per-directory basis when it is modifying the repository (eg for a tag or commit). If a ,v file is symlinked into multiple directories, two different CVS processes might believe that they have "the lock" that allows them free reign over that file, and one will end up clobbering the other. A symlink of a directory, on the other hand, likely won't cause any problems. but of course, you can do that via a modules file entry... > The political issues that you raise are correct, though, testing becomes > much more complex, I generally use it for simple header files and junk > that doesn't change much.. That would lower the likelyhood of a corrupted file, but not completely eliminate the possibility. > Please, backup and _test_ your backups before you go doing anything that > involves hopping in to the repository directly.. I'll go along with that. Heck, I even do a backup before every import, just in case I do something fumble-fingered. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
[EMAIL PROTECTED] (Larry Jones) writes: > Laine Stump writes: > > > > That's great, but your example doesn't use the tags normally suggested > > in the results of imports, eg "-j NET:yesterday -j NET" (which in this > > case wouldn't work anyway because it had been less than a day between > > imports, but that's beside the point). > > No, but it shows that the basic functionality does work. If it didn't > work for you, then either you're running an old version of CVS. Nope. 1.11 server, straight from (post-1.11) CVS on client. > or you did something wrong. Unless the cvs import command is giving "wrong" instructions, I am not doing anything "wrong". CVS is not performing as you described in your original email message on the subject. Note the emphasized phrase below: [EMAIL PROTECTED] (Larry Jones) writes: > Doing the merge that CVS suggests when there are conflicts (even if ^ > there aren't any conflicts) will mark the appropriate files for > deletion. Committing the results of the merge will then delete them. If you want to modify your statement to say "Doing a merge using the tags placed on the branch at the time of the last two imports" (or something similar), we'll be in complete agreement, but currently the merge that cvs suggests does nothing of the sort, so either your statement is incorrect, or there is a bug in cvs. As for your example, it is *not* doing the merge that the cvs import command suggests. It names specific tags (eg -j FIRST -j SECOND), while the cvs import command recommends using two *branch* tags, the first with a date offset specifier (eg -jNET:yesterday -jNET). When I use specific tags as you did in your example, it does of course work as you say (as I said in my last reply). However, when I use branch tags as suggested by cvs import, no files are deleted. Following is an example based on yours that demonstrates what I'm talking about - note that 1) I used the merge command recommended by cvs import when it found a conflict, and 2) nothing is marked for deletion, as your message claimed would happen. (One small deviation - I used "-jNET:'2 minutes ago'" rather than "-jNET:yesterday" since it had been less than a day since the first import. The results would be the same if I waited for another day and then used "-jNET:yesterday" however. If you remain unconvinced, I can do the same command over again with a one day wait in the middle ;-)) # date; echo file1 >file1; echo file2 >file2; cvs import -m first tst NET FIRST Thu Mar 22 15:08:46 EST 2001 N tst/file1 N tst/file2 No conflicts created by this import # checkout a workspace and modify file2 to create a conflict on next import # cvs co tst U tst/file1 U tst/file2 # cd tst # echo more file2 >>file2 # cvs commit -m"local commit" Checking in file2; /vol/cvsroot/tst/file2,v <-- file2 new revision: 1.2; previous revision: 1.1 done # cd .. # rm -rf tst # make some changes in dir to be imported - remove file1, modify file2 # so there will be a conflict, create file3 # rm file1 # echo more imported file2 >>file2 # echo file3 >file3 # date; cvs import -m second tst NET SECOND Thu Mar 22 15:11:27 EST 2001 N tst/file3 C tst/file2 1 conflicts created by this import. Use the following command to help the merge: ===> cvs checkout -jNET:yesterday -jNET tst # Note that at this point, more than two minutes have passed since the # first import, and less than two minutes since the 2nd (only a few # seconds, actually). The fact that it gives us the change to file2 # from the vendor branch verifies that we have the timing correct. # cvs suggested "-jNET:yesterday -jNET", but we know that it hasn't been # a full day yet, so we use '2 minutes ago' as the time specifier. ===> # cvs co -jNET:'2 minutes ago' -jNET tst U tst/file1 U tst/file2 RCS file: /vol/cvsroot/tst/file2,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.2 Merging differences between 1.1.1.1 and 1.1.1.2 into file2 rcsmerge: warning: conflicts during merge U tst/file3 # (Note - no messages indicating files scheduled for deletion) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Is there a Perl CVS Module?
John Tucker <[EMAIL PROTECTED]> writes:
> Hello,
> I want to execute CVS commands from a
> perl script I'm writing. Does anyone
> know where I can get a Perl CVS module?
Is there something you can't accomplish by just using:
system("cvs ");
?
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Accidentally merged out code.
"Alexander Kamilewicz" <[EMAIL PROTECTED]> writes: > Andy Bradford wrote: > > > > Thus said "Alexander Kamilewicz" on Wed, 28 Mar 2001 10:24:34 CST: > > > > > > Usually this is caused by someone doing an update while they have a file > > > > loaded into a text editor and then saving the file over top of the > > > > merged version (wiping out the merged changes) and then committing it. > > > > > > LOL!!! That's pretty clever. I hope my developers don't find out about > > > that > > > > While it might be clever, it is certainly a nightmare when trying to > > figure out why their code disappeared. Then, try explaining to them > > that this is not the correct way to use it. :-) > > That's why I've got this large baseball bat here :) And fortunately most text editors (at least the ones I use, ie emacs and MS Visual Studio) are smart enough to notice when this happens, and at least give a warning before overwriting the updated copy. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Module variable
[EMAIL PROTECTED] (Larry Jones) writes: > Nick Flowers writes: > > > > I'm modifying the server so that a developer committing > > a change automatically causes an export to our staging > > webserver. > > Why? Is there some reason the method shown in "Keeping a checked out > copy" in the manual won't work? > > http://www.cvshome.org/docs/manual/cvs_18.html#SEC171 My problem with that was that it was (potentially) run as a different user each time, resulting in permission errors (since the users don't have g+w in their umask). I just wrote a short setuid program that executed the same command. I also seem to recall that it gets called once for each file, which leads to bunches of "waiting for xxx's lock on yyy" messages when a single cvs commit ends up committing multiple files (since multiple copies of it are running at once). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
Jerry Nairn <[EMAIL PROTECTED]> writes: > Also worth mentioning in this thread is the fact that most of the files > generated by InstallShield and the associated tool, Package for the Web, are > ordinary text. Yes, the unfortunate part is that InstallShield insists on using long names with embedded spaces for directories and files, which leads to odd inconveniences occasionally (eg, cvs -n update doesn't work properly, you can't use "find . -print | xargs ...", etc). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
[EMAIL PROTECTED] (Larry Jones) writes: > Laine Stump writes: > > > > Yes, the unfortunate part is that InstallShield insists on using long > > names with embedded spaces for directories and files, which leads to > > odd inconveniences occasionally (eg, cvs -n update doesn't work > > properly, > > What goes wrong? When I look at it more closely, I find: 1) It's not that big a deal. 2) it probably occurs when the directory names *don't* have spaces, too. (I just happened to notice it in a directory that had spaces in the name, and made a rash assumption). What I saw was a message like this: cvs update: New directory `ishield/Setup Files/Compressed Files/0009-English/Intel 32' -- ignored When the given directory is in the repository but empty (and I have -P in my .cvsrc, ie the directory doesn't exist in my workspace). When I do update without -n, no message about the empty directory is printed. It seems like "-n update" should notice that the directory is empty and -P is on, and print nothing. But, as I said, it's not a big deal. > > you can't use "find . -print | xargs ...", etc). > > You can if you have the GNU versions of find and xargs: > > find . -print0 | xargs -0 ... > > (Actually, all you need is GNU xargs: > > find . -print | tr '\n' '\0' | xargs -0 ... > > although various versions of tr have slightly different syntaxes, so you > might have to fool around a bit to get exactly the right incantation.) Cool! Now that you say it, I think I remember seeing that before, but it didn't stick with me then because I didn't need it. After this, I promise I'll remember it! ;-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Latest core CVS source
[EMAIL PROTECTED] (Larry Jones) writes: > That's because when you check things out of CVS, the files' timestamps > are set to the current time rather than the time they were committed > (for good reason) I thought that was only the case for updates, not for checkout. The initial checkout gives files the timestamp of the commit for the revision being checked out. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS from RCS?
[EMAIL PROTECTED] writes: > Id like to add that if I remember correctly, it is possible to > create RCS files that will not be usable in CVS. For one example, > if you have revisions of the form 1.x.y.z then is it not the case > that these will confuse CVS? We did that (ie, converted a bunch of files having revisions like "24.1.2.1" fomr SCCS to RCS, then put them into a CVS repository) at a previous place I worked, and encountered no problems. (Note that when we wanted to create new branches after this point, we did it in the normal CVS manner). AFAIK, the only numeric branches that CVS treats in a special manner are 1) the 1.1.1 branch, which is used for vendor imports, and 2) branches ending in ".0.x", whre "x" is some even number - in case (2), this isn't a problem, because RCS would never create a branch or revision with "0" as one of its components. It *is* entirely possible that someone might have created a 1.1.1 branch in RCS to use for "normal" purposes. I think this might cause problems IFF the file had no revision beyond 1.1 on the trunk (since a checkout of the trunk from CVS would give you the tip of the 1.1.1 branch rather than rev 1.1) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Default CVS_RSH
[EMAIL PROTECTED] (Larry Jones) writes: > Ben Elliston writes: > > > > May I suggest that future versions of CVS set the default setting for > > CVS_RSH to "ssh"? That is by far the more common setting for :ext: > > authentication. > > And just how did you come to that conclusion? I wondered that too. Based on my own "survey of one", I'd say that the most popular setting (and definitely the simplest) is the current default. Aside from that, ssh is not standard on many platforms (try to remember that the entire world is not running Redhat Linux), which would mean that setting up a minimal CVS system would be more complex (either they have to install ssh, or they have to set CVS_RSH), which would inevitably lead to multitudes of posts on this mailing list asking the same question over and over (and over and over...). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checkout error
[EMAIL PROTECTED] (Larry Jones) writes: > Robert Penland writes: > > > > cvs server: cannot open /root/.cvsignore: Permission Denied > > cvs [server aborted]: can't chdir(/root): Permission Denied > > http://cvshome.org/docs/manual/cvs_21.html#SEC182 > > If you need more explicit help, see the archives of this list. > You know, as often as this gets asked (what is it, about 6 times a week? More?), maybe the error message printed should have something like this tacked onto the end: Congratulations! You've encountering the #1 asked FAQ in CVS! Please read http://cvshome.org/docs/manual/cvs_21.html#SEC182 to learn how to fix this problem. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Clarification needed on determining checkout/in status.
Richard Sharp <[EMAIL PROTECTED]> writes: > it is my understanding that to determine whether a module is checked out or > in is to : > > "cvs his -ao" this lists all the files that have been or are, checked out > - look for you module and check the date/time of the most recent entry. > > "cvs his -ac"this lists all the files that have been or are, checked in - > look for you module and check the date/time of the most recent entry. > > If the date of the first command is older than the date of the second > command - then that module is checked out. > > If the date of the first command is younger than the date of the second > command - then that module is checked in. > > Is this correct ? No. In CVS "checked out" is not a state, it is an action. Likewise, "checked in" is not a state, but also is an action. You are thinking in terms of other version control systems, which use the term "checked out" to indicate the state of a file that has been locked by a single user for exclusive write privileges, and "checked in" for the state of a file that was locked by a user, but is no longer locked, since that user committed their changes to the source control repository. In CVS "checking out" a file is the act of getting a local copy in your work directory, and "checking in" is the act of committing changes; multiple people can edit a file at once, so there is no need for a "checked out" *status* with CVS. What you're probably looking for is the edit status of a file - read the manual sections about "cvs edit" and "cvs watch", oh and "cvs status" (and the rest of the manual, so you'll understand the difference in philosophy between CVS and systems like PVCS, SCCS, RCS, and SourceSafe). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Renaming a branch
Jim Harkins <[EMAIL PROTECTED]> writes: > Like an idiot I came up with a branch name that is not only too long and > unwieldy, but it no longer accurately reflects it's contents. Is there a > good way to rename a branch? As long as you can prevent other people from accessing the repository while the script is running, you can just run an awk (perl, whatever you're most comfortable) script that searches for the old branchname in the ,v files and replaces it with the new branch name. To prevent changing lines in the actual source that may coincidentally contain the same name, only do it between the first line that matches "^symbols" and the first line that matches "^locks" (I'm basing this on a quick look at a ,v file). > The only option I can think of is to create a new branch, populate it with > my trunk at time t0, then merge in my crappy name, test, swear, test some > more, then delete the original branch. Is there a better way (like an awk > script to frob all the ,v files in my Repository?) > > I don't want to merge my branch to the trunk, the trunk is a set of vendor > code that gets modified for various projects. > > jim > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: importing vendor branches
"David L. Martin" <[EMAIL PROTECTED]> writes: > When a new RCS file is created as a result of cvs import, the > RCS archive's default branch is 1.1.1. When/If the first local modification > is committed, the default branch becomes blank (= the trunk). See the > output of cvs log in the "Branch:" field. The tip of the default branch > appears to be what is regarded by CVS as the revision to retrive > in an update -A. > > To make update -A retrieve the trunk revision (1.1) for locally > unmodified files which have been imported, you could use cvs admin -b > on all files created by the import to force the default branch to be empty > (i.e. the trunk). > > To avoid this mess, you might consider moving your development > from the trunk to a branch. You'd be guaranteed that a vendor > import would not affect the contents of your development branch, > until you decide to merge the vendor branch deltas yourself using > standard merge procedures. Another way to "fix" this is to just force a "null commit" (new revision, but 0 lines changed) on the trunk of each new file right after it is initially imported. Once you've done this, a checkout on the trunk will give only things that have been explicitly committed to the trunk, never anything directly from the vendor branch. The next time you do an import, the changes will be only on the vendor branch until you do a merge to the trunk (which should be painless for the locally-unmodified files, since there won't be any conflicts). This *will* mean that each change on the vendor branch will result in a new rev on the trunk, which may or may not displease you. (sorry if this method was already brought up - I got into the conversation late, and had already deleted all the old posts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: importing vendor branches
[EMAIL PROTECTED] (Larry Jones) writes: > Greg A. Woods writes: > > > > I still don't see the problem here. If everyone who might do a checkout > > reads at least the subject lines of the mail from loginfo they'll know > > when an import was done, and in what module, and be able to avoid doing > > a fresh checkout that might result in an inconsistent working directory. > > Note that it's not just a fresh checkout; a plain update has the same > problem. Right. And not all merges are simple 10 minute deals, and not all repositories are used by less than 10 people. Imagine some significant portion of 100 engineers breathing down your neck because they can't do any commits, updates, or checkouts during the week that it takes you to resolve merge conflicts due to a new import (sure, it should be designed so that actual conflicts in the imported files takes much less time than that, but let's suppose that the new import changes some functionality, and that requires a rewrite of portions of locally developed code in order to work correctly; anyway, even a *day* is a long time, especially in a project with a lot of people, where tomorrow someone else might do yet another import of something different which again renders the repository "temporarily unusable"). If you're really concerned about the concept of "concurrent development", then you should make all changes dealing with a specific piece of new functionality, whether these changes are from the vendor or done locally, show up on the trunk at the same time. Doing otherwise restricts the productivity of the other developers (it's really just an unenforced read lock on the entire repository) and is extremely impolite (with the level of impoliteness increasing as a square of the number of developers using the same repository and a cube of the number of hours the repository is in an inconsistent state). Me? I'm lucky - the only CVS repositories that I commit to these days have at most 3 people working on them, so I can afford to be impolite ;-) (On the other hand, I'm unlucky that the repository used by lots of people is still under VSS, which doesn't even have a *bad* vendor branch concept, much less a good one (and also doesn't allow scheduling adds and deletes to happen simultaneous with a commit). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: MS Visual C++ Version
"Jerzy Kaczorowski" <[EMAIL PROTECTED]> writes: > When VC70 comes out there is no problem at all, because it uses > totally different file format as well as a new extension for those > new files. The workspace is now called a solution (*.sln) and a > project files are in XML format with the extension vcproj > (*.vcproj). > > I am not sure whether VC40 reads a VC60, but I would think so. It doesn't. VC4 uses makefiles (.mak), VC5 and VC6 use project and workspace files (.dsp and .dsw). > I think it is a good idea to keep the files under VC50 format unless > somone can provide the VC60 version that uses some VC60 features > which improve the build version (not present in older versions that > is). I think that whoever is donating the time to maintain the make/project files for VC should do it in whatever format is the most convenient for them, and everyone else should either live with it, or donate *their* time to supply project files for the older/newer versions. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log between tags
[EMAIL PROTECTED] (Greg A. Woods) writes: > [ On Saturday, May 5, 2001 at 19:51:00 (-0400), Larry Jones wrote: ] > > > > cvs -H log says, in part: > > > > -r[revisions] Specify revision(s)s to list. > >rev1:rev2 Between rev1 and rev2, including rev1 and rev2. > >rev1::rev2 Between rev1 and rev2, excluding rev1 and rev2. > > > > I think :: was new in CVS 1.11.1. > > Unfortunately neither are useful for the most common case I want to use > (which I suspect is what Jim wants too). > > I want to find all the log entries between releases, which to me means > after the first tag and up until and including the second one. In other > words I need: > > Between rev1 and rev2, excluding rev1 and including rev2. > > Seeing that last log entry is just as important as not seeing the first > one. Good point. I want (through *some* method) exactly the same functionality as you, and I imagine many others do too. I had suggested implementing the "::" syntax for log because ":" was already there for log and admin, "::" was already supported for the admin command to mean "exclusive of the first and last revisions", and my feeble mind was at the time thinking something along the lines of "since the tag happens *after* the last revision is committed, that last revision will be included in the logs". Of course that thinking is flawed... (I hadn't yet noticed, because I was waiting for it to be in an official release before doing anything with it.) So is there an actual use for a command that excludes that last revision from the log? Since this is a newly implemented option, maybe the meaning can be changed slightly to mean "only revisions that were committed after the first tag, and prior to the last". Since the revision with the same number as the last tag was, by definition, committed prior to making the tag, this would give us what we want (ie, it would include that last revision), and wouldn't skew the meaning *too much* from what it means elsewhere ;-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about auto login
"Liwei Chour" <[EMAIL PROTECTED]> writes: > I use CVS for several month, It is good for me. But I have one > question about auto-login. Beacuse I need to build program everyday > in different machines, I should login CVS server, checkout code, > build code and logout. I want these process automatically, so I > write a shell command file to do this job. But I need login CVS > first. How do I write auto-login shell command ? You don't need to. When you first login (successfully) to any cvs server, the password information is stored in an encrypted form in the .cvspass file in your home directory. After this initial login, you never need to use the "cvs login" command for that same server ever again. (Yes, .cvspass saves passwords from multiple servers). (Note: if you want to "forget" the password for a particular server, you can run the "cvs logout" command, which will erase that password from .cvspass. You will then need to run "cvs login" again for that server before you can use it again.) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Suspicious email message intercepted
Donald Sharp <[EMAIL PROTECTED]> writes: > What happens if someone wants to post a vbs script that works with > cvs? They can zip the file before sending it, or (even better) send a pointer to a webpage that contains the script rather than clogging up everyone's mail spools with file attachments. Of course a more important part of the solution would be for the servers sending out these virus reports to be configured to not reply to mailing lists, but you can bet that'll never happen :-( ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Questions on the vss3cvs script
"Diedrich, David" <[EMAIL PROTECTED]> writes: > I'm in the process of converting some sourcesafe files to CVS using > your vss2cvs perl script and have q couple of questions on its use. > > How does the perl script use cvs.exe and ss.exe; I did'nt see a place in the > script on where the pointer to these executables where used so I'm wondering > if I'm missing something. Uh, look at just about any use of the function "exec_cmd". It is used in many *many* places to call cvs as well as to call ss (the VSS commandline utility). It is assumed that these commands (and a few others) are somewhere in the system executable path, as mentioned in the ReadMe.txt file that you can find in the same location as the script. > I've installed the cygwin Unix utility package on my PC and I'm working in > the cygwin Unix shell. The command line use of vss2cvs script goes as > follows: perl vss2cvs option option option . . . > > According to the script the options work like this > > perl vss2cvs workdir ssroot cvsroot ssproj cvsbranch ssuserpass Although nothing ever says that is the case, I guess I didn't make the way it *does* work clear enough in the documentation. Options to the script are *NOT* determined by their position on the commandline. There are two ways to specify options: 1) set an environment variable that has the same name as the option prior to calling the script. For example: set WORKDIR=c:/sscvwork * see note set SSROOT=c:/test * see note set CVSROOT=/cygdrive/g/CVSTEST set SSPROJ=projectname/subproject perl vss2cvs.pl 2) enter the environment variable settings on the commandline, in option=value syntax. For example: perl vss2cvs.pl WORKDIR=c:/sscvwork SSROOT=c:/test CVSROOT=/cygdrive/g/CVSTEST SSPROJ=projectname/subproject > I'm assuming that this command line inputs are my root directories so are my > doing this right if I enter the options like follows: > > perl vss2cvs /cygdrive/c/sscvwork /cygdrive/c/test > /cygdrive/g/CVSTEST projectname optional optional. Nope. See above. Also read the ReadMe.txt file and the script itself - the documentation is haphazard and missing some things, but everything is revealed in the source. Now, for some notes (most all of these are also in ReadMe.txt, but they're important so I'll repeat them): 1) DO NOT install/use the perl that comes with cygwin - see the ReadMe for the reason. Install ActivePerl instead. http://www.activeperl.com. 2) I prefer to not use the cvs.exe that comes with cygwin, because a) it makes me use the /cygdrive/x/dir notation, which is a pain to type, and gets confusing/creates problems when you're trying to use the same directory names with other applications that *aren't* cygwin, and b) I've seen it screw up in some areas where it behaves half like a unix cvs and half like a DOS cvs (sorry, I don't remember the details right now). Instead, install a standard Windows cvs binary built with MSVC++. 3) If you're going to be doing things from within a cygwin shell (or, better yet, bash, which is a part of cygwin), keep in mind that the options to vss2cvs.pl are mostly for the use of ss.exe and cvs.exe. Even though you're running these commands from within a cygwin shell, they still understand only the normal DOS/Windows location of files - for example, they understand c:/test, NOT /cygdrive/c/test. As long as you use ActivePerl, and a standard (non-cygwin) cvs.exe), NONE of the options will use the /cygdrive/... notation. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: remove!
Bob Andrews <[EMAIL PROTECTED]> writes: > My computer, on which I have my password stored, in in > storage in another city. > > The email address is [EMAIL PROTECTED] Please > unsubscribe me ASAP. I am on the road with a laptop, > and the volume from this is killing me. Just go to this URL: http://mail.gnu.org/mailman/options/info-cvs/rba%40infocorps.net and click on the "Send me my password" button, then click on the "disable" button and cut-n-paste the password you subsequently receive into the Password field at the bottom of the page. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvswrappers - any better suggestions ?
"Echlin, Michael" <[EMAIL PROTECTED]> writes: > There are problems with binary files in cm. when you start adding many > revisions to an archive you get an archive file that suddenly becomes very > large, with some documents having a size of 6 to 20 megs even 10 revisions > is a large file to hunt through to get at the particular version of the > document, and with our particular industry the documents are live for the > life of the system they describe and that life expectancy is 40 years. This may not be the case for the document processor program you're using, but many word processors allow saving in .RTF format, which is a text file. People using such a word processor (MS Word is an example) could just save all their documents in that format, which should greatly reduce the size of diffs between revisions. > That and let me specify what program I will use to show the diff of that > type of file. (Word does diffs of word files, excel does diffs of excel > files...) I know how to make Word show me a diff of two files from the menu, but don't know how to do it from a DOS commandline, and I've been *dying* to find out (I could then setup tkCVS to use it); I even searched the MSDN documentation and didn't find anything. Do you (or anybody else on the list) know how to do this? Note that subversion (http://subversion.tigris.org) *will* have support for diff "plugins", I believe both for viewing and for storing (not sure about the 2nd). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: RCS to CVS migration
Jeeva Chelladhurai <[EMAIL PROTECTED]> writes: > Hi there, > > We have been using RCS as our source code control system. Right now we > are planning to migrate to CVS, however we wanna preserve the rcs logs, > meaning we should still be able to see the good old logs in cvs. Could > you pls. guide me how to do that. > > Also pls let me know if there is any tool that could easly RCS source > branch and conver it into CVS. CVS uses RCS files to store revision history. Just initialize your cvs repository with "cvs init" (this creates a subdirectory in your cvsroot called CVSROOT that contains some administrative files), then move all your RCS ,v files into a directory hierarchy below your cvsroot. That's it, you're done! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: problem with LF <--> CRLF trasnlation
Mike Castle <[EMAIL PROTECTED]> writes: > Do NOT check out using Windows on to a Samba share, then edit on the Unix > box. > > Do NOT check out using Linux onto a Windows share mounted with smbfs and > then edit on the Windows box. > > It will cause you no end of grief if you try to mix and match platforms > that have different line-ending policies. > > Just don't do it. Or, if you insist on living dangerously (as I do) use editors and compilers that are smart enough to distinguish the type of line ending in a file, and behave accordingly. Examples of editors: Emacs on any platform, or PFE (Programmer's File Editor) on Windows. Examples of compilers: MSVC++ on Windows (just don't use the builtin editor), gcc on any platform, *NOT* GNU make or BSD make, if I recall correctly. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Newby : moving/renaming files loses version information?
"Hondros, Constantine" <[EMAIL PROTECTED]> writes: > Does moving / renaming a file in CVS necessarily mean that the "new" file > ends up at version 1.1? If you do it in the way you describe (which is the only way that I know about to do it without directly frobbing the repository) then yes. > I followed the instructions at the (excellent) red-bean CVS tutorial thusly > : > > floss$ mv oldname newname > floss$ cvs remove oldname > floss$ cvs add newname > floss$ cvs ci -m "renamed oldname to newname" oldname newname > > and found that the "newname" file started at version 1.1. > > Is this situation avoidable? Yes, if you're willing to move things around in the repository itself, and if you're willing for the resulting file to show up in the old location when you do a checkout based on an old date or tag. Just do this: 1) in the repository, do "cp oldname,v newname,v" 2) in a work directory, do "rm oldname; cvs remove oldname; cvs commit" 3) Still in the work directory, do "cvs update" to get a working copy of newname. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Newby : moving/renaming files loses version information?
[EMAIL PROTECTED] (Greg A. Woods) writes: > I find nothing whatsoever "awkward" about the remove/add scheme. It > works perfectly as far as I can tell. The awkwardness is in breaking > any pre-concieved and incorrect notions users might have about what a > rename operation actually is. It makes it more difficult to do a diff of a revision of the file pre-move with one that is post-move, especially with a frontend such as tkCVS, which presents you with a graphical representation of the file history, then allows you to click on the two revisions you want to diff. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Newby : moving/renaming files loses version information?
[EMAIL PROTECTED] (Greg A. Woods) writes: > It could use "cvs ls", but that's rather hackish IMHO. And nothing else you've proposed is ;-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS LOGIN
Christian Robottom Reis <[EMAIL PROTECTED]> writes: > On Wed, 16 May 2001, G. Shi wrote: > > > However, it seems that cvs login is interactive. Is > > there any way to include login, update logout in a > > script? > > You could use expect(1) to automate that, and you could also use the new > password syntax that pserver offers now -- I believe only 1.11 has it, > however. Or just never "logout". The only "state" from a cvs login command that makes you "logged in" is an encrypted form of your password stored in the .cvspass file in your home directory, and although I haven't looked, I'm guessing that all "cvs logout" does is to erase the appropriate line from that file. Just do cvs login once, then never do it again - then your script can do the update and nothing else. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: problem with keywords and crlf
[EMAIL PROTECTED] (Larry Jones) writes: > No. CVS uses the "correct" line endings for the platform where it's > running. Not if the "platform" is a combination of different OSes and editors used during different parts of the development process (which is the case quite often these days). (I've resisted the urge to put several arguments supporting explicit line-ending handling in CVS here, as I just don't have the energy to debate it; instead I'll patiently wait for Subversion to pass Milestone 3, then try my luck convincing them instead...) > It sounds like you checked the file out on Windows and then > committed changes on Linux. That isn't possible. If you have checked out on Windows, attempts to run a Unix version of CVS on the work directory will fail completely, since CVS gets confused by the CRLF in the administrative files in the /CVS subdirectory. A more likely happening would be that the file was originally created with CRLF's and "cvs added" using the Linux cvs. The CRs in the lines would be seen as just another character. If he then did a checkout on Linux, made some modifications with an editor that understood CRLF line endings, and did a commit from Linux, he would end up with a file that had CRLF for most line endings, but LF-only for the $log stuff. If all the files in the repository are text files, this can be solved by closing down the repository for awhile and running a dos2unix converter over every ,v file. "tr -d '\r\'" usually works decently, as a part of an appropriate shell script. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: list modules
Christian Robottom Reis <[EMAIL PROTECTED]> writes: > On Sun, 20 May 2001, Andy Nuss wrote: > > > 1. list modules on server, > > 2. choose the module I want, > > AFAICS this _is_ obtainable using 'cvs history', but it seems like a hack. > I don't know if anybody has a better solution, though. For toplevel modules, use "cvs co -c", which will list all modules that are in the CVSROOT/modules file. To see what directories/files are below these, look for "cvsls" in the mailing list archives. It makes creative use of the cvs rdiff command to get a complete listing without actually doing a checkout. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: vss2cvs migration of shared files
Manik Bafna <[EMAIL PROTECTED]> writes: > There are files in VSS shared across projects and > shared between directories in the same project. > We are migrating from VSS to CVS. > What is the right strategy for migration of shared files. > > 1. Break the link and maintain as two separate files This is easiest in the short term, but a very bad idea in the long term, since it requires developers to maintain two copies of the same file. > 2. Break the link and keep only one copy. > This will require change in build scripts and source code. This has the problem that you note, but seems to be the best approach for long term sanity (when combined with option (3) for entire directories that are shared). > 3. Is there a way where I have only one copy > of the file in the CVS repository and when I > checkout I get multiple copies of the same file > (I'm not sure whether it is possible using modules). > Are there any implications using this method. You can share entire directories with entries in the modules file, but that won't work for individual files. In VSS it is possible to share a single file between two directories in the repository. There is no equivalent functionality in CVS. Some people emulate it by symlinking the ,v file in the repository into multiple directories, but doing so is begging for trouble, since CVS sets mutex locks on a per-directory basis to prevent multiple processes simultaneously writing to the same ,v file during commits and tags. Having a ,v file existent in two directories breaks the data model that is assumed for proper operation of these locks, and will eventually lead to a corrupted file. > I'm using Laine Stump's scripts for migration. You flatter me. I only put them on a web site and hack them now and then ;-) The scripts were originally written by Jerry Nairn. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: vss2cvs migration of shared files
Manik Bafna <[EMAIL PROTECTED]> writes: > BTW when trying to migrate from VSS to CVS found that > it does not migrate deleted files. How to fix this problem. I'm not aware of any method to get information or history for file deleted from VSS without undeleting them first. If you know of a way to use the "ss" commandline utility to get a list of deleted files, and to retrieve old versions of those files, without undeleting them, let me know and I'll try adding support for that into vss2cvs. Or, better yet, do it yourself and send me the patches! ;-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: vss2cvs migration of shared files
> > Manik Bafna <[EMAIL PROTECTED]> writes:
> > > BTW when trying to migrate from VSS to CVS found that
> > > it does not migrate deleted files. How to fix this problem.
> Laine Stump wrote:
> > I'm not aware of any method to get information or history for file
> > deleted from VSS without undeleting them first. If you know of a way
> > to use the "ss" commandline utility to get a list of deleted files,
> > and to retrieve old versions of those files, without undeleting them,
> > let me know and I'll try adding support for that into vss2cvs.
Manik Bafna <[EMAIL PROTECTED]> writes:
> What is the issue if I mark undeleted, migrate and mark deleted again.
> I know VSS creates new versions for files and projects if we undelete or
> delete.
> Will this create any problem.
There is no issue there (as long as nobody else is using your VSS
repository at the time), and that's how I've always assumed it would
need to be done. However, what I asked for was actual VSS commandlines
to get a list of the deleted files. I don't have the time or desire to
go wading through VSS documentation to figure out the right
commandline parameters.
> To list the files/projects deleted:
>
> ListDeleted (PROJECT)
> {
>
>LIST all the files/subprojects deleted in PROJECT
>foreach element in the LIST {
>recover element
>if(element is a subproject/folder) {
>ListDeleted(element)
>delete the element
>}
>print element
>}
> }
>
>
> By this we could list current deleted files/project in the VSS.
> Similar code could be written to recover, migrate and mark deleted again.
>
> Regards,
> Manik
>
>
> >
> >
> > Or, better yet, do it yourself and send me the patches! ;-)
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Browsing the repository
David Fuller <[EMAIL PROTECTED]> writes: > Except that 'cvs co -c' only lists out the available modules, not what > is in those modules. I agree with Andre, this would be a "good" feature > to add to CVS. Except that the logistics of it are problematic. Look up "cvsls" in the mailing list archives. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tag modules ??
> "Zanabria, Moises" wrote: > > I'm concern ,the typical method is to check-out the src code and only tag > > that. > > My question . > > How can the modules file get tagged during the build process? > > Must it be checked-out to tag it? Matthew Riechers <[EMAIL PROTECTED]> writes: > cvs rtag module_name I believe what's being asked is how to tag the modules file (in the CVSROOT directory) itself, not how to tag the contents of the module without checking it out (which is what your answer does). That could likely be done with "cvs rtag CVSROOT/modules ...". However, it wouldn't do you much good at all, since CVS always uses the most recent revision (on the trunk) of the modules file, even when doing checkouts based on tags/branches/dates/etc. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Advantages and Disadvantages of CVSNT
What about the capabilities of commitinfo, loginfo, taginfo. I would imagine those must be limited on an NT server, since it won't have all the same commands available. (I'm just guessing though, as I've never run it on NT. It's something you should investigate though). Also, what about the more flexible remote administration (Of course that's and argument for Unix rather than NT in general, so presumably your admin has already chosen to ignore that point). And I would reiterate the point that CVSNT is a *port* of CVS, not just another platform that the main source can be built for. That means that there is a delay before new features/bugfixes in the main code find their way into cvsnt. Mathias Meyer <[EMAIL PROTECTED]> writes: > on Dienstag, 12. Juni 2001 11:23 you wrote: > > > Um, I don't have much experience with the Windows CVS server, but the > > Windows filesystem is case insensitive and Linux's isn't. Linux > is > > more reliable in general. More development work goes on on CVS > > servers on UNIX systems, so bugs should show up less often and get > > fixed more quickly. > > > > http://www.cvsnt.org might have some useful data. > > > They certainly might do, but I didn't find anything, that would > convince my Admin to run CVS under Linux, which I prefer too. They just > mention people who use CVSNT and are satisfied with that ;) > Of course you can't expect developers to reduce the quality of their > product. The case-insensitivity is a good point, but people who like to > use Windows don't care about that. > > But thanks anyway. > Seems like I'll have to cvs with NT ;( > Best Regards. > -- > Mathias Meyer > www.dynamicwebpages.de > www.beatsteaks.de > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS/Vis Studio 6
"Matt Keyes" <[EMAIL PROTECTED]> writes: > I had created several projects under Visual Studio 6 (Vis C++). I > imported the ASCII files (i.e. .h, .cpp) to CVS with the following > command (run from the Linux box... I transferred the files there > first): > > cvs import -m "Source Code" Source mkeyes start > > [...] > > Now then, when I checkout the ASCII files and open them under Visual > Studio 6, I get the following message: > > Lines ending with only a carriage return detected. > These will be modified to include a linefeed. > > Then, as the message states, I get two linefeeds for every one I had > previously. When I go back and correct the formatting error, commit > it, then check it out and look at it again, it looks fine. However, > I get the feeling that I might be missing something. Any help is > appreciated. > To solve your problem, erase the newly created module from CVS, then redo the import, but do it from a Windows box. The problem is that your original files have all lines terminated with CRLF (as they were created on Windows), and the Unix CVS client does no translation, so everything goes into CVS with CRLF (in spite of the fact that the RCS ,v file format is supposed to have just LF for line termination). Then when you checkout with a Windows client, it translates: line of text into line of text (ie it translates the Unix line ending into Windows ). There are those of us who believe that CVS should be more intelligent about line ending conventions, but we are squelched by those who believe that elegance and simplicity of design is more important than robustness and correct operation (and who apparently never have to do serious development in a mixed Unix/Windows/Mac environment). Or something like that ;-) (Yes, I've given up.) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Good Win32 Diff Program...
Matthew Riechers <[EMAIL PROTECTED]> writes: > IMHO, GUI diff tools are only more useful when merging files by hand > (drag 'n drop lines, etc). This scenario should hardly come up under > typical use of CVS, since it merges for you. Readability of GUI or CLI > styles is a matter of taste. One thing a GUI diff *can not* do is > directly integrate with arbitrary development tools (i.e. SLOC report > generators, etc.) One thing the output of "cvs diff" cannot do is be easily and quickly parsed by a human brain when the diff is large and has many changes within existing lines (yes, even a "context" diff is more trouble to grok than something that is nicely colorized, with the two files displayed side-by-side). Almost without exception, I use diff wrt. CVS when I want to quickly see what changed between two revisions of a file (ie "what did they screw up *this* time? ;-), and that's a royal pain with a pure-text diff, if it's more than a few lines long. My favorite visual diff is ediff, which is part of emacs (emacs also has CVS integration builtin, so you can get cvs diffs displayed with ediff in 3 keystrokes); I like it because 1) it colorizes modified *words* within the diffs (not just modified *lines*), making it easier to see exactly what changed, and 2) it is part of my favorite editor, and one of the copies of the file being displayed is usually the copy in the work directory, so I can modify it right then and there, rather than having to switch back and forth between my editor, and another copy of the file in a read-only diff program. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Import/Conversion utility for CVS
Bil Joga <[EMAIL PROTECTED]> writes: > Is there a utility that will convert a Microsoft Visual Sourcesafe > database to CVS format? http://www.laine.org/cvs/vss2cvs Be sure to read both the ReadMe.txt file and the source code itself before asking questions. Most of the answers are there, they're just a bit unorganized ;-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Code for drawing a diagram of a revision tree?
James Youngman <[EMAIL PROTECTED]> writes: > Are there any tools out there for drawing a diagram of the delta tree > for a CVS file (or in fact code for doing this with any > revision-controlled file would be useful). There's WinCVS I know, > but is there anything else? There's code to do it using Tcl/Tk in tkCVS - http://www.twobarleycorns.net/tkcvs.html. I believe logcanvas.tcl is the file you want to see. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Anybody converted VSS history to CVS?
Greg A. Woods writes: > > Yeah, no thanks to the broken use of sccs2rcs. Unfortunately nobody > ever wrote an "sccs2cvs" that would properly translate an SCCS > repository into CVS using CVS semanitcs. Speaking of converting to CVS from other systems - has anyone ever converted a Visual SourceSafe repo into CVS? If so, do you have a script laying around? I've convinced "the powers" that we need to switch from VSS to CVS, but we've got several years worth of VSS history and I'd much prefer to retain it in the switch. (Said "powers" don't see any advantage to doing this, but I know from experience how useful things like cvs annotate are.)
RE: Anybody converted VSS history to CVS?
Jerry Nairn writes: > Well, > I had to do this, VSS to CVS conversion, so I hacked my way around it. Maybe > if someone else has more time and is more determined to do a good job of it, > they can take what I've done and make it nicer. I did this for myself, not > for general consumption. WOW! Thanks! Even with the warts like shared files/directories (which I was figuring I'd have to handle manually anyway), this will *definitely* save us loads of time. This is something that really should go into the contrib directory of the CVS distribution. After all of us evangelizing about how much better CVS is than VSS, it would be really nice if the converted masses had an easily locateable and available method of translating their repositories.
Re: CVS support for /cvs rm -rf/???
Shawn Anderson writes: > BlankAm trying to figure out the best way to transport full directory > hierarchies into the Attic. If I were to do the following:: > > > > $: rm -rf modulename [except CVS dirs] > > $: cvs -rm -rf modulename > > $: cvs ci -m "removed directory" modulename How about something like this? (from a working directory): find . -type f -print | grep -v CVS |\ while read f; do rm "$f"; cvs remove "$f"; done find . -type d -print | grep -v CVS | sort -r |\ while read f; do cvs remove "$f"; done cvs commit -m"Move everything in directory X to Attic" (the "sort -r" is a hack to get it to place subdirectories before their parents in the list. Quotes are necessary around the "$f" in case you have any directories filenames with spaces in them.) /bin/sh is your friend (and /bin/bash is your co-conspirator).
Re: browser-based interface to CVS
Shai Tamari writes: > I would like to set up a system of source control with a browser-based > interface. Ideally, users could download files from a main server, view > history, diff, etc. from any remote machine using their browsers. Is it > possible to build this/set this up with CVS? You mean like this? http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/ That's an example of what can be done with this package: http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi/ I've seen this (or similar) script used in several open source projects. My only wish is that it would highlight the exact character differences between revisions (as cvs-ediff in emacs does), rather than just entire lines. Even so, it's still very useful.
WinCVS List modules on the server feature does not work
Vadim Bartlov writes: > Hi, > When I try to go to [CVSAdmin]->[MacrosAdmin]->[List the modules on the > server], it doesn't list the modules. > Can anyone tell me how to get that option working? What I've been wondering is why the "Modules" tab in the left pane of the WinCVS window shows a directory tree of C:\ instead of listing the modules in my repository. Everything else seems to work properly, including listing of the modules file (well, I would have some suggestions about some things, but that's another topic) - am I misunderstanding the purpose of the "Modules" tab? (Does anybody else wish that either WinCVS would take the best features of tkCVS, or vice versa? They're both very promising, but neither has the full set of capabilities / ease of use, to permit me to recommend them to our soon-to-be-ex VSS users as a replacement for the VSS GUI. In both cases, it's still much easier to just use the commandline for most operations.)
WinCVS and the info-cvs mailing list
Larry Jones writes: > CVS, which is what this mailing list > focuses on, is a command-line utility > [...] > WinCVS is a completely separate (though related) > product. Oddly, http://www.wincvs.org points people at this mailing list (the CVS mailing list) when they have questions about WinCVS. I'm not sure why they haven't setup their own mailing list, as other frontends, such as tkCVS, have. It would seem to make *a lot* of sense to do so...
CVS scenario -- who "owns" a working directory?
Stuart R Dole writes: > I've discovered that when I cd into a working directory, > after logging-in to cvs, that cvs doesn't like me to do > things unless the name in CVS/Root is me. This makes sense, > but since there's several of us that telnet into the > "workstation" and modify files, each one needs to edit the > file CVS/Root to match themselves. (I haven't figured out a > good way to simply let each user have his/her own working > directory -- there's one working directory on the > workstation that we all share, because of the way all the > scripts are set up... The workstation is really an embedded > system with custom hardware on it that we're constantly > testing.) > > So, is there a simple way to tell CVS that a new guy is now > in the working directory and messing with the files, other > than manually editing the CVS/Root file? If I do this, is > there more I need to be doing too? Ignoring problems with file and directory permissions associated with having multiple users playing around in the same sandbox (which I'm assuming you've already worked out), if you're using rsh client-server (rather than pserver), when you do the initial checkout just omit the username from the CVSROOT specification - it will assume the current username. So, for example, instead of setting CVSROOT to: [EMAIL PROTECTED]:/cvsroot you would set it to: cvsserver.company.com:/cvsroot If you're logged into the local machine as joeblow at the time you do the checkout, it will do the checkout in the name of joeblow, and set all the CVS/Root files to "cvsserver.company.com:/cvsroot". After that time, whatever user is currently logged in will be used for the rsh to the cvs server for subsequent cvs commands. This doesn't work in pserver mode, and doesn't work if the client machine has no concept of "user". I have used it in the past on Unix boxes to allow other users to do cvs diff in my work directories, though, and it works just fine. Note that you can also start doing this after the fact - just do a short shell script to replace all the CVS/Root files with new files that have the proper CVSROOT setting.
Re: CVS scenario -- who "owns" a working directory?
Larry Jones writes: > Yuck! How do you prevent two people from telnetting in to the same > workstation and stepping on each other's changes? CVS was never > intended to handle that kind of an environment. About the only thing I > can suggest is always doing ``cvs -d $CVSROOT'' to override CVS/Root. Although it's obviously fraught with perils, and I would never *want* to do it, I've been forced to share work directories between 3 or 4 people in the past, due to limited resources on the machine in question. While it did cause inconvenience and frustration at times (eg, somebody is halfway through making a change in some other directory and you try to do a "make all" which fails because of syntax errors in their not-yet-completed code), it is at least marginally workable in a pinch. Very definitely if there is enough space, having separate work directories is a much better answer. If there's not enough local disk space, how about having each user NFS-mount their work directory from somewhere else? (that would also allow you to run cvs itself on another machine (the NFS server), thus removing that burden from this apparently minimal target machine.)
Re: CVS scenario -- who "owns" a working directory?
[EMAIL PROTECTED] writes: > "Limited resources"??? Disk space is practically free these days! > Last week's local ads had a 27GB disk for $150; that's about $5 per > gigabyte. You're assuming that every piece of hardware has the capability of connecting an IDE disk. There's a whole world out there beyond the bounds of desktop Intel PCs, and lots of them don't have *any* spinning media *at all* (or capability to attach spinning media), much less multiple GBs. Don't assume that the economics of mass market PCs can be extrapolated to the entire realm of computer hardware. Of course there are many other ways to setup your development environment to get around the problem - beyond NFS-mounting extra disk from somewhere else, an even better idea would be to use cross-development tools running on a standard workstation to do all editing/building, and use the embedded device only for (remotely-controlled) debugging, thus removing the need to have any source whatsoever on the target system. But that wasn't what the original poster asked about, they asked how to enable different users to run cvs commands in the same work directory. (BTW, that *does* have uses - as I mentioned in my previous mail, we used to use cvs-ediff in emacs to review other developers' changes as part of the full pre-commit peer review process; being able to do the diff directly in the other person's work directory saved *a lot* of time).
Re: [cciug] general makefile (and script) style rule
David Boyce writes: > For the record, there's one option you haven't discussed: > > CLEARTOOL := C:/Progra~1/Rational/ClearCase/bin/cleartool.exe That can't be guaranteed to be correct across multiple machines. If another "long" filename beginning with "Progra" was created on the disk prior to the creation of "Program Files", *it* will be PROGRA~1, and "Program Files" will be "PROGRA~2" (or ~3 or ~4). Obviously in this case that's not very likely (since the Program Files directory is created during the initial Windows Install), but in the general case it is much more likely to happen.
Re: CVS Code Freeze and 1.11 Test Release Available
Matthias Kranz writes: > The problem is probably, that there is no one out there feeling really > responsible for saying "Yes" or "No" or "Please adjust your contribution > in this manner ...". The guys of OpenAv seem to be reserved about > leading the development and who else do you think should accept or deny > the patches? I'll answer your question with a question. Both may have the same (or at least a similar) answer: "Who has commit access to the CVS repository for CVS?"
Re: CVS checkout filename with space (bug fixed ??)
> > Gerhard Ahuis writes: > >> > >> I have some trouble checking out files with spaces in the name. After some > >> queries on deja news I found that its a bug in cvs. > >> Is this bug fixed at the moment, are there patches ?? I have files with spaces in them (not by choice - InstallShield saves some project info in files containing spaces in the names), and the only trouble I've had is spurious messages when doing cvs update from a parent directory of the directory containing the "spacey file". add, checkout, and commit work just fine (from the cvs commandline, at least). I'm using 1.10.8, but I believe it was working this way with 1.10 as well. > Larry Jones <[EMAIL PROTECTED]> wrote: > > No. Most of the core of CVS handles spaces in filenames correctly, but > > there are lots of little bits and pieces that don't and so far none of > > the developers has been sufficiently motivated to track them all down > > and fix them. Gerhard Ahuis writes: > What about the cvs checkout part ? Because this is the reason why cvsweb > cannot download filenames with spaces from the repository. Is there a > way to get around this problem..? Are you sure the problem isn't with cvsweb?
Re: Entries Files with a Tag line item prevents Commit --WHY ???
TC writes: > So What is the CVS correct way to revert to a previous revision > & edit it, & then have this new edit version of the previous revision > become the HEAD for this file ??? Something like this: # make sure you don't have any sticky tags cvs update -A file.ext # get the older revision without setting a sticky tag # (see the documentation for update -p) cvs update -r -p file.ext >file.ext # edit the file # commit the "new" revision, which is identical to "old-rev" cvs commit file.ext Just make sure you're not wiping out any modifications that you *didn't* want to trashcan!
Re: Is it possible to have a mirror CVS server
> [ On Thursday, September 7, 2000 at 18:21:55 (+0530), Ramesh Chander wrote: ] > > Subject: Is it possible to have a mirror CVS server > > > > We want some kind of mechanism where our team work use a CVS server > > which is at our local site and replicant server at remote site. > > If we commit on this local server then some how it update the remote > > repositry and vice versa. [EMAIL PROTECTED] (Greg A. Woods) writes: > This is simply not possible within the design parameters of CVS. > > The only way you could reasonably do this would be to mirror the remote > repository at your site (using rsync or CVSup, or even just ftp, etc.) > and then use that to create a second vendor-branched repository also at > your local site. Do all of your changes to the trunk of the second > repository (i.e. in working directories checked out from the second > repository). Then finally pick appropriate periods in time to tag your > local work, create a great big patch containing all the changes since > the last tag, and commit them to the master repository. Repeat this > cycle as appropriate. A much simpler method, which gains *many* of the advantages (but not all), is to periodically rsync or CVSup a mirror of the main CVS repository to the satellite locations, and use that as a *read-only* repository, switching to the main repository when it comes time to do a final update & commit. This can be handled with a couple of scripts that cycle through a work directory changing the contents of every CVS/Root and CVS/Repository file (one to switch from main to mirror, another to switch from mirror to main). At any given time, the mirror may be slightly out of date, but that will be corrected by switching to the main and doing a CVS update prior to final testing and commit. (One thing to watch out for - users updating from the mirror while an rsync/CVSup is in progress)
Re: source code for rcs57nt / cvs-1.9-win?
Donald Sharp <[EMAIL PROTECTED]> writes: > If you can't guarantee the correct time as you import than > you shouldn't import the time stamps( just say it's lost ). Or, modify the script to first get the dates for every revision of a file, then "normalize" all those dates, store them in an array, and use those dates during the conversion. You could do something like: * start at the final revision - if its date is > current, set it to the current date * For each previous version, make sure its date is at most one second prior to the next higher revision's date. As long as your only date problem is with dates set too far into the future, this should give you something reasonably workable. BTW, does this vss2rcs.js script handle updating already existing RCS files with new revisions from VSS, or do you start over from scratch every day? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
building CVS 1.11 on WinNT
Has anyone been successful at building CVS 1.11 on WinNT? I've tried it with both MSVC 5.0 and 6.0 (and I *think* I treid it awhile back with 4.2), and they all fail at some point. If you've been able to build it, can you give a synopsis of what you had to do? Is there any plan to put a Win32 client binary up at cvshome.org? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: building CVS 1.11 on WinNT
"Derek R. Price" <[EMAIL PROTECTED]> writes: > Haven't played too much with the actual project file, but this patch for > the cvsnt.mak file should be compatible with the nmake distributed as far > back as VC++ 4.0. It used to build under 4.0 and it now builds 1.11 > & 1.11.0.1 under my 6.0. Yep, that patch fixed it. In particular, the problem I was having was that version.obj wasn't in the place that the makefile expected it when linking: link.exe @E:\TEMP\nma00203. LINK : fatal error LNK1104: cannot open file ".\WinDebug\1\version.obj" NMAKE : fatal error U1077: 'link.exe' : return code '0x450' Stop. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: [Cvsnt] cvs + M$ Integration with VS IDE]
Tony Hoyle <[EMAIL PROTECTED]> writes: > The site seems to be down ATM. He can't distribute source because he > has signed a Microsoft NDA. > > A way around this would be for his program to execute the real > cvs.exe, and communicate with it through pipes. I believe that > would remove the violation, since CVS would then be a separate > process. The way you previously explained it, he was calling a GPL'ed DLL - that's the same (in the eyes of the GPL) as executing a separate binary. He's not violating the GPL unless his program links in GPL'ed code *at compile time*; runtime is okay. (Of course he should check this out with a lawyer to be sure, but that's the way I've always understood it.) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: [Cvsnt] cvs + M$ Integration with VS IDE]
Tony Hoyle <[EMAIL PROTECTED]> writes: > Laine Stump wrote: > > The way you previously explained it, he was calling a GPL'ed DLL - > > that's the same (in the eyes of the GPL) as executing a separate > > binary. He's not violating the GPL unless his program links in GPL'ed > > code *at compile time*; runtime is okay. (Of course he should check > > this out with a lawyer to be sure, but that's the way I've always > > understood it.) > > No... DLLs are linked at compile time, just like unix .so files. They > are merely loaded dynamically. As a matter of fact, I'm at this moment looking at a Microsoft Platform SDK documentation, which states that there are two ways of calling a function in a DLL: "loadtime linking", and "runtime linking". The *implib* is linked at compile time, not the DLL itself. The implib contains the info necessary to load the DLL and do the fixups so that the DLL functions will be called; this fixup (ie "linking") happens at program *load* time. Note that an IMPLIB is *extremely* simple, and it's very straightforward to create your own implib for a DLL without any access to the source (as long as you know the names of the functions; in some cases you'll need to know the "ordinal number" of the functions as well, depending on how the DLL was built); the result would be that you are linking with *your* (license of your choice) implib at compiletime, and only linking the (GPL'ed) DLL at loadtime. Alternately, you can build your program with no implib at all, and have your application load the DLL explicitly, using the LoadLibrary() function call, then GetProcAddress() to find the addresses of all the functions you want to use. In this case you are not even linking at load time, but at *run* time. (to be completely "clean", you'd want to not use any .h files that had the GPL on them either) So, fortunately you are incorrect. The only real question is whether or not loadtime/runtime linking is considered "linking" for purposes of the GPL. Since it is acceptable, for example, to have a proprietary LKM that gets "linked" into the Linux kernel at boottime/runtime, I'd say that it looks like it *is* acceptable, but again, I'm not an authority on the intracacies of the GPL. > >From the GPL: > > This General Public License does not permit incorporating your > program into proprietary programs. If your program is a subroutine > library, you may consider it more useful to permit linking > proprietary applications with the library. If this is what you want > to do, use the GNU Library General Public License instead of this > License. If you are calling a GPL'ed DLL, you are not incorporating that DLL into your program, you are merely calling it; almost exactly the same as if you were calling cvs.exe with system(). If this weren't acceptable, NetBSD, FreeBSD, and OpenBSD would all be in violation of the GPL, because they load and execute GPL'ed binaries. I'd venture to guess that the legality of those 3 OSes has been closely scrutinized, so again this looks like no problem. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
updates to vss2cvs.pl (VSS to CVS conversion perl script)
I've spent some time in the last few weeks hacking at Jerry Nairn's vss2cvs.pl script (and a bit on massagecomments.pl), and have made some changes that I think others will find useful while converting from VSS to CVS. You can find my modified versions at: http://www.laine.org/cvs/vss2cvs Look in the file README for details of the changes. A short summary of the important changes: 1) vss2cvs.pl is now re-startable, so you can re-run it after changes have been checked in to VSS (as long as you've kept CVS read-only), rather than being forced to redo the conversion from scratch. This can significantly shorten the downtime when you do the final switchover. massagecomments.pl can also now be re-run on a ,v file without destroying it, for the same reason. 2) Options processing is now more flexible, and easier to understand. 3) VSS branches (at least the way *our* VSS people do branches) are now handled. See the README for details. At some point maybe these scripts will become useful enough that they should be put into the cvs contrib directory... (I know they're certainly useful to me!) P.S. Thanks for posting your scripts, Jerry. They've been a real lifesaver! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Branching
You need to set the "sticky tag" for the file/directory to R3-07-01: cvs update -r R3-07-01 It probably current has a sticky tag of R3-07-02, which is a *non*branch tag, and cvs won't allow you to commit in that case (it only allows you to commit if there's no sticky tag at all (ie, you're at the end of the trunk) or if the sticky tag is a branch tag (ie, you're at the tip of a branch). Tommy McNeese <[EMAIL PROTECTED]> writes: > Branching question. > If I have the a file main.c > > It's current HEAD is 2.18 > > On revision 2.16 I have a branch with a tag name R2-19-01. > > I then tag R2-19-01 to R2-19-02. > > When I try to commit to the branch it says I can commit because it's not a > branch. > > Here is what CVS display when I do a cvs log main.c > > RCS file: /home/cvsroot/proj1/main.c,v > Working file: main.c > head: 2.18 > branch: > locks: strict > access list: > symbolic names: > R3-07-02: 2.16 > R3-07-01: 2.16.0.2 > .. > .. > .. > > >From looking above, CVS did make a branch on R3-07-01, so why can't I commit > anything to it? > > Thanks, > Tommy > > > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Migrating from VSS to CVS
Ephraim Ofir <[EMAIL PROTECTED]> writes: > Any advice and tips would be greatly appreciated. My first advice would be to look back through the info-cvs archives (I forget where they are, but I believe the email you received when you subscribed should point you at them) for "VSS" or "Source Safe". Beyond that, there are a few scripts written by Jerry Nairn which I enhanced a bit and put at: http://www.laine.org/cvs/vss2cvs Roughly speaking, this is the *mechanics* of the actual conversion of the repository using these tools: 1) On a Windows PC that has access to both the VSS and the CVS repository, install perl 5.6.0, cvs, and vss. Run vss2cvs.pl (possibly multiple times (for multiple projects and branches), figuring out the appropriate arguments). (Actually, I'd recommend initially doing the conversion to a CVSROOT on local disk, then moving that CVSROOT to the intended server - it's much faster that way). 2) On the CVS server, cd to the subdirectory of the cvsroot directory that contains the projects newly converted from VSS and do something like: find . -name \*,v -print | while read f; do massagecomments.pl "$f"; done This takes date+user info for the commits that was stored in comments by vss2cvs, and moves it into the "real" date+user fields. For us, the difficult part is figuring out what to do with linked files. VSS can link a single file in the repository to multiple places in the work directories. CVS supports a similar functionality (via the CVSROOT/modules file), but only for complete directories. We still haven't decided on a final method of dealing with this (we'll probably have to restructure our directories and makefiles in some way), but a program that will help you in making an informed decision about this is Jerry's "listshares.pl", which I've also enhanced a bit and put in the same directory. In short, listshares.pl produces a list of "directory sets", with each one followed by a list of all the files that are shared in exactly that set of directories (for those of you that previously used the program, if had produced a list that had a separate entry for each file, rather than grouping all files with identical shares together; the new format is *much* smaller and more informative). If anyone has any suggestions on what to do about files that are linked in CVS (yes, we've already considered symlinks in the repository, but that seems to be a bad idea for several reasons), I'd love to heard them. Once you've converted (btw, before doing that you'll want to get in some practice using CVS, determine how to map your currect "daily source control tasks" into CVS operations, and write up a short "cheat sheet" tutorial for all your developers on how CVS can be simply used in *your* environment. You may also want to look at the various GUIs for CVS. My personal preference is TkCVS (you can find the latest release, along with discussion, etc, by searching for "tkcvs" on http://www.sourceforge.net), but some others prefer wincvs (maccvs, gcvs), or some others. You'll find it takes some getting used to if you're accustomed to the VSS GUI, and a few reporting capabilities are missing (eg, a list of all commits between two particular dates), but you'll also find some things that *aren't* in VSS (eg, a graphical tree of all the different revisions and branches of a file, easy merging of changes between branches, etc.) Finally, read *everything* in the CVS manuals / FAQs / tutorials about how evil file locking is, and how wonderful it is to *not* use it. CVS does allow you to lock files for exclusive modification, but with very few exceptions you *don't* want to do this. You'll probably find that CVS' concurrent development model scares the hell out of some of your VSS-accustomed developers, so make sure you know all the arguments on both sides, so you can calm them down - once they get used to it, they won't believe they could have ever lived with the locking model ;-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: HELP - How to stop line break conversion?
"David L. Martin" <[EMAIL PROTECTED]> writes: > Ross, > > > How can we stop WinCVS/cvs/whatever is > > to blame from converting text files, so that the Windows machine has > > Unix-style files on? > > > > Recent WinCVS versions (at least since1.1b8) have the option in > Admin>>Preferences Global tab of checking out ASCII files with Unix LF. > Check this box. Be aware that you may need to do a new checkout since the > CVS/* administrative files in the working area are also affected by this > option. It seems like it would make a lot of sense if the CVS commandline on all platforms (automatically) understood all different line-ending conventions in the CVS/* files. Likewise, it would also make a lot of sense if it checked the existing file during updates/diffs/etc and converted to whatever line-end convention was already in use for each (non-binary) file in the working directory (alternately, if that made anyone uneasy, the line-ending type could be stored in the Entries file, just like tag info, but that wouldn't be backwards compatible). For those of us who poke around the same work directory with both Unix and Windows versions of tools, this would make life much more convenient. Of course, if this was all combined with a cvs commandline switch to force line-end convention on checkout (the default would still be system-dependent), *AND* if checkin always converted files to newline-only regardless of platform and workdir convention, life would be very good indeed. ;-) (yeah yeah, now go ahead and tell me what a stupid idea this is. I know how the system works... :-/ ) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: New Server, old Repository
"Ashley M. Kirchner" <[EMAIL PROTECTED]> writes: > My old CVS server was brought down to its knees during an OS upgrade > and I found myself having to install CVS from scratch on a different > machine. So, I now have cvs-1.11 installed on the new server, and I'm > stuck. > > From the OLD server, I tarred up the /CVS repository (which contains > CVSROOT, and source directories for the projects), and I also checked > out every project and tarred them up. > > If I import those sources right now, as far as the CVS server is > concerned, it considers them new. I won't have any of the (older) > revisions, right? So, what's the best way to rebuild the CVS > repositories, maintaining everything that was on the old server? > Someone I don't think it'll be as simple as just copying the old /CVS > (tar) back into the new /CVS directory. Or is it? Yes, it is. Just untar your tarred up repository directory, then setup any inetd entry you may have had for pserver mode, .rhosts files for access via rsh, or mounts for "local" access using NFS (a bad idea, btw), and everything should be set. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: New Server, old Repository
Mike Castle <[EMAIL PROTECTED]> writes: > If the server has a different name, or the directory structure isn't > exactly the same, everyone will have to recheck out their code with a > different -d CVSROOT option. If there are not check in changes, they may > want to save the old checked out stuff to be sure to catch it. Rather than taking the chance of missing some changes in their old work directory, they could just run a small script to change the contents of CVS/Root in each subdirectory of their working directory. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and revision range
[EMAIL PROTECTED] (Larry Jones) writes: > Thierry Leconte writes: > > > > Now I want to know all changes between two symbolic tags. > > cvs log must do the job, but if, for some files, the 2 revisions > > coresponding > > to the 2 tags are on different branch cvs log will not work properly. > > > > This is in the FAQ, but I wonder why cvs log could not handle this case > > : > > is it a well know bug that nobody have time to fix or is there a more > > serious reason ? > > "Between" really isn't meaningful for revisions on different branches. Sure it is, you just have to think about it a bit differently. It could be displayed as a set of "reverse logs" going from the first tag backwards to the common branchpoint, then "forward logs" to the 2nd tag. Bonus points could be added for detected "reverse" and "forward" revisions that cancelled each other out (could be done by comparing the diffs of each revision, but would fail if there were any small branch-specific changes in one or the other). I'm not sure how the reverse logs could be displayed in the output - perhaps with "-" at the beginning of every line or something... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and revision range
[EMAIL PROTECTED] (Guus Leeuw) writes: > > HEAD: 1.4 > BRANCH1_HEAD: 1.2.1.1 > BRANCH2_HEAD: 1.3.1.1 > > What's the common branchpoint for BRANCH2_HEAD and BRANCH1_HEAD? > There isn't any... untill we hit 1.1(.1.1)... Which is too way back in the past. What is the definition of "too way back in the past"? Any two versions in cvs have a common branchpoint *somewhere* in the past, and that point "is what it is"; I don't see how any point would be "too far". The common branchpoint (according to what I *meant*, at least ;-) of 1.2.1.1 and 1.3.1.1, btw, is 1.2, not 1.1: (*) 1.1 --- 1.2 --- 1.3 --- 1.4 \ \ \ \-- 1.3.1.1 --- 1.3.1.2 \ \-- 1.2.1.1 --- 1.2.1.2 As an example, a log of changes between 1.3.1.2 and 1.2.1.2 would be: - 1.3.1.2 log - 1.3.1.1 log - 1.3 log + 1.2.1.1 log + 1.2.1.2 log (Note to purists: Yes, I realize that CVS would itself never choose x.x.1.1 for any branch (except for 1.1.1.1 for the vendor branch). If it makes you feel better, just replace all 1.x.1.x with 1.x.2.x ;-) (Note 2: I'm not actually suggesting that somebody *should* implement this, just pointing out that the raw information is available, it is possible, and someone sufficiently motivated *could* implement it if they wanted.) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
updates to vss2cvs.pl script
Based on some enhancements and ideas I received from Ephraim Ofir, and finding some bugs during a fairly large conversion attempt, I've updated vss2cvs.pl and put the new version at: http://www.laine.org/cvs/vss2cvs Here's my commit log of the changes. Note that the two bugs I found/fixed could be important for anyone who previously converted and didn't watch the output for errors - you may have ended up with incomplete/inaccurate history! revision 1.5 date: 2000/11/09 19:50:38; author: laine; state: Exp; lines: +91 -111 * Change method of setting entire directory to branch to speed things up (idea from Ephraim Ofir). * Gather list of filenames from ss dir command rather than running separate ss properties command, again speeding things up (idea and code from Ephraim Ofir). NOTE: this may break the ability to properly convert files which are in the "save latest version only" mode in VSS - I don't have any such files, so I can't say for sure. * don't make cvs add dependent on finding a revision 1 of file in VSS - sometimes they start at a different revision (idea from Ephraim, code from me). * Explicitly supply directory name to ss get to avoid inadvertant gets to the wrong directory "when ss feels like it". * Add -r global option to cvs co, update, commit commands to guarantee that file in working dir is always read-only (otherwise, ss get barfs). The lack of this, and of the previous change, had caused numerous incorrect results in the past. * add access mode to mkdir call, so the script will run with older (5.00x) versions of perl. = ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Getting list of files in a module
[EMAIL PROTECTED] writes: > I've just installed CVS 1.11. I'm trying to get a list of the files in > a module without having checked the files in that module out, by > running: > cvs -n checkout myprog Try: cvs rdiff -s -D 01/01/1971 You'll then want to do some chopping with your favorite scripting language. Look up "cvsls" in the mailing list archives for more information about this cute hack. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs - modules query
iag <[EMAIL PROTECTED]> writes: > > So what I'm trying to do is have files in a single workspace directory > contain files from multiple repository directories and having played around > with alias modules, etc., I still can't see how (or if?) cvs supports this. > It complains as soon as I try to specify a module which takes files from a > second repository directory and try to put them into a workspace directory > that's already got stuff in it from another repository directory. What you're looking for is something analogous to VSS' "sharing" concept, where a single work directory can contain files that are stored in multiple directories in the repository. This is not possible with CVS, since it specifies the repository location of files on a per-directory basis, not per file. The best you can do is to "share" entire directories using the modules file. Personally, I try to avoid "sharing" as much as possible, since it can lead to situations where you can't *really* test your changes until after you've committed them, then updated the other locations in the project where those files exist (which violates many teams' rule of only committing code that has been thoroughly tested). Aside from that, the modules setup isn't version controlled, so if your project depends on directories shared in using modules, and you change the modules setup, you could end up not being able to accurately reproduce an older version of code. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS co-existing with RCS?
Don't do this! CVS uses lock files (to avoid simlutaneous modification of the same ,v file by different processes) which are not known to RCS. Because of this, using RCS and CVS at the same time can lead to corrupted files. Bruce Cota <[EMAIL PROTECTED]> writes: > It seems taht CVS and RCS history files are identical, but that CVS > and RCS expect those files to be in different places (a CVS repository > in one case, the current directory or an RCS subdirectory in the other > case). > > So, could I get away with making sym-links called "RCS" from a common > working directory into a CVS repository, so that some developers could > use rcs commands from the common directory while others use cvs to > access the repository? > > This is to provide a transition for a site that currently uses RCS to > support a web-based application. The development web server uses the > most recently checked out html files, CGIs, etc and a big, complex > makefile moves the most recently checked in files from the RCS > subdirectories to a test server or production server. I'm pushing > hard to move us to CVS, but only a few users will have their own web > servers to work with, so only they will be able to use CVS "as it is > intended". Changing the build system (which expects RCS > subdirectories) is also tricky. > > So I'm wondering if we can allow most users (and the build system) to > continue use RCS while a few users switch to CVS. > > The big wrinkle I see is that when a user commits changes to the CVS > repository, those changes will not become visible in the working > directory which is under RCS control. > > Is there anything else wrong with this plan? > > Thanks for any advice. > > -Bruce Cota > > > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ampersand module question
Laird Nelson <[EMAIL PROTECTED]> writes: > I'm curious about ampersand modules. > > Once a regular module (containing another module via the "&" construct) > is checked out, does that module actually *know* that it contains the > contained module? > > If my modules file says something like this: > > frobnicator frobnicator &caturgiator > > ...and I do this: > > cvs checkout -P frobnicator > > ...then I get this (as expected): > > frobnicator/somedir > frobnicator/caturgiator/someotherdir > > ...but now if I do this: > > cd frobnicator; rm -rf caturgiator; cd .. > > ...and then do this: > > cvs -q update -d -P -A > > ...then caturgiator does not reappear, suggesting that frobnicator's CVS > directory does not record what the modules file engineered to happen. Correct. there isn't enough info about submodules in the upperlevel CVS directory to bring it back, and cvs update ignores the modules file. > The only way to set this back up would be to re-checkout the project or > checkout the caturgiator module directly at this level. I believe if you do cvs checkout from above the toplevel of an existing work directory, and it will update what's already there, and add anything new that it finds in the modules file. It won't *remove* anything that was taken out of the modules file, though. > Is that by design? It seems more likely it was just an accident of implementation. The entire modules file concept doesn't seem very well thought out to me; more like an afterthought tacked on one rainy afternoon... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: history of the tags (was: hitory of the tags)
Donald Sharp <[EMAIL PROTECTED]> writes: > The thing that really concerns me about this is that the history file > can get quite large and will tend to grow much quicker now with these > changes. This is the problem I have with it too. Any such "history" feature that isn't scalable without needing to regularly trim off the "old" history is of extremely limited value. It is especially bad if it creates problems for those who don't need/want its info. It's too bad the RCS file format doesn't put dates with the tag info, but of course even that would be just an "acceptable" (still not ideal) solution to a single problem. Perhaps it's time to think about adding a new and different type of storage to the server side of CVS, based on some sort of simple database format. This would take more thought, discussion, and design than just adding on something that uses the currently available data files, but we'd end up with something more useful and expandable in the long run. Having said that, I agree that, in the current framework, the best solution is for people wanting that info to install a taginfo script. > For instance we had a repository with a history > file that was 118megs. And imagine how large it would be if it had * more lines in it! > Parsing that took quite some time, and in the > end we just removed the history file as that we didn't feel that it > actually provided us with usefull information. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: What is the best way to mount remote repositories?
>From the description of what you're proposing, It sounds like each site has its "main" projects (which aren't worked on much by other sites) and needs occasional access to projects mainly worked on by the other sites. Some recommendations: 1) NEVER NEVER NEVER NFS-mount a CVS repository!!! 2) Setup a CVS repository locally at each site that contains only the "main" projects for that site, make those repositories accessible via ssh, rsh, or pserver mode, and just use different CVSROOT settings to checkout the SITE_A and SITE_B projects. Once you've done the initial checkouts to your work directories, you won't need to specify the alternate CVSROOT for update, diff, commit, etc commands - CVS figures it out by itself. P.S. Make sure you give each CVS repository its own local CVSROOT - don't try to NFS-mount it either (as you've suggested in your original message) "Jean-Claude Gervais" <[EMAIL PROTECTED]> writes: > Hello, > > > I work for a company that has offices in many different cities and > the Internet connects them all by VPN. > > There is source-code development work being done at all these sites, > and naturally, we'd like to access each other's source repositories. > > For example, let's consider that there are two sites, initially. > > We've tried installing one CVS server at SITE_A, and then remotely > logging in by CVS and TKCVS from SITE_B, but through the VPN connection, it > is very slow and unreliable. Worse, if ever the route to SITE_A is down (and > it does happen), then the developers at SITE_B are unable to perform any CVS > functions. > > The most important criteria for selecting a strategy to do this are > speed and reliability. How can we achieve this? > > The current strategy we're evaluating is this: > > First we put everything in Site A's CVS, including site B's > projects, with the following organization: > > /cvsroot/software/projects > SITE_A_PROJECT1 > SITE_A_PROJECT2 > CVSROOT > SITE_B_PROJECTS > > At SITE_A, we create NFS shares for SITE_A_PROJECT1, > SITE_A_PROJECT2 and CVSROOT. > > At SITE_B, we setup a CVS server. We move the > SITE_B_PROJECTS folder from SITE_A to SITE_B's CVS root folder and share it > with NFS. > > Then we mount SITE_A_PROJECT1, SITE_A_PROJECT2 and CVSROOT > from SITE_A in SITE_B's CVS root folder. > At SITE_A, we mount SITE_B_PROJECTS back where it was. > > So after this, both systems look like this: > > SITE_A: > > /cvsroot/software/projects > SITE_A_PROJECT1 Local folder (fast!) > SITE_A_PROJECT2 Local folder (fast!) > CVSROOT Local folder (fast!) > SITE_B_PROJECTS Mounted NFS share from SITE_B > > SITE_B: > > /usr/local/cvsroot > SITE_A_PROJECT1 Mounted NFS share from SITE_A > SITE_A_PROJECT2 Mounted NFS share from SITE_A > CVSROOT Mounted NFS share from SITE_A (a bit > slow *sniff*) > SITE_B_PROJECTS Local folder (fast!) > > > CVSROOT must be the same for both systems to keep in synch, > so that is why SITE_B must mount it and thus pay a performance penalty. But > I hope this will not be too dramatic. > > > So, the question is: Is this the right way to do this? > > > We're newbies at this, so please, be gentle! :-) > > Thank You. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: WinCVS like tool for Linux/X Windows?
Laurent Duperval <[EMAIL PROTECTED]> writes: > On 12 Jan, Deever, Chris C. wrote: > > Does anyone know of or use a WinCVS like program for X under Linux? > > > > If you're a Tcl fan: http://tkcvs.sourceforge.net If you look at tkcvs, you may want to try out the in-development "canvas" branch of the code that is available from the tkcvs CVS repository at sourceforge (rather than just checking out the latest release from the trunk). It is *much* nicer visually, making it easier to understand what you're looking at. Now if it just allowed full "tree-style" browsing of both work directories and the repository, and got rid of those few last uses of "check out" (where it should say "update"), it would really "whoop the llama's ass" ;-) (Sorry, you won't get that joke if you aren't a WinAmp user...) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: cvs admin - delete version]
[EMAIL PROTECTED] (Larry Jones) writes: > Usage: cvs admin [options] files... > ... > -o range Delete (outdate) specified range of revisions: >rev1::rev2 Between rev1 and rev2, excluding rev1 and rev2. >rev:: After rev on the same branch. >::rev Before rev on the same branch. >rev Just rev. >rev1:rev2 Between rev1 and rev2, including rev1 and rev2. >rev:rev and following revisions on the same branch. >:revrev and previous revisions on the same branch. Gee, it would be nice if cvs log also accepted the "::" notation... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: My first stumper ...
"Derek R. Price" <[EMAIL PROTECTED]> writes: > That shouldn't cause the problem. A standard update uses the revision and > not the date to compute the diff. All the date comparisons going on should > be on the client against records of dates it set in the first place. And *that* causes a problem of its own in another circumstance. While playing with vss2cvs, I found that (on WinNT) if you do a commit, modify a file, then do another commit within 1 second, the commit will do nothing since CVS believes that the file is unmodified. I don't know if there's any practical way to get around this, other than forcing the commit with -f (that's what I did). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: cvs admin - delete version]
[EMAIL PROTECTED] (Larry Jones) writes: > Laine Stump writes: > > > > Gee, it would be nice if cvs log also accepted the "::" notation... > > Your wish is my command -- I just checked in a change to do that. Wow! Talk about service! How long until the next official release? (in other words "Should I wait for a release, or throw caution to the wind and start running from the anoncvs sources?") ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: My first stumper ...
[EMAIL PROTECTED] (Larry Jones) writes: > CVS tries to avoid this problem by sleeping until the time is later than > the timestamp of the most recent file before it exits. This works > perfectly on Unix-like systems where file timestamps have the same > granularity as time() does. Unfortunately, the FAT filesystem (and > presumably NTFS as well) has a timestamp granularity of two seconds > whereas time()'s granularity is only one second, so there's a one second > window for error. I've thought about changing it to sleep until at > least two seconds have elapsed, but I'm not sure that's such a good idea > -- it's not necessary on Unix and it may not be sufficient for some > other obscure system. I agree. > > I don't know if there's any practical way to get around this, other > > than forcing the commit with -f (that's what I did). > > You can always touch the file and do a normal commit. Except that this is in a script, and the whole idea is to make it run as fast as possible (ie, it *still* wouldn't be "enough later" by the time the script touched the file). I'm pretty much resigned to just doing commit -f (unless I feel like rewriting the script to cycle between multiple files). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
