Problems with permissions on files and directories
I am using cvs pserver and am seeing some permissions problems on files and directories *in* the repository. Sometimes we see directories with permissions such as rwxrwxr-x, thus people who are members of the others group cannot merge changes with their own changes, we get a "read lock failed - giving up" Sometimes I see files with the following permissions: r--r--rw- Makefile,v I am not sure whether this is a problem or not with files. How do I ensure that directories are given rwxrwxrwx permissions with specific owner and groups and files are given r--r--r-- permissions with specific owner and groups? Regards John Scott. Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using the reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail may be accessed. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: configuring mail-addresses
Various solutions suggest themselves:
1: (the right way :-) Configure sendmail(8) to do 'site hiding'
(masquerading)
This is not as hard as it might first appear. Look in:
(I was going to suggest using the MACROS {m4} way of
building sendmail.cf
with help and advice from www.sendmail.org {works for me}
but I just spotted that linuxconf has an option to do
exactly this :-)
2: add 'reply-to' headers (not quite what you asked to do but it
might be
all you need.
3: Send using sendmail(8) rather than mail(1) (uuugh!) with the -f
option.
Rather depends on what userid your 'mail sending process' is
running as.
--
Graeme
Message: 2
From: Dirk Naujoks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: configuring mail-addresses
Date: Mon, 9 Apr 2001 08:59:00 +0200
Hi,
I've got the following situation:
There's a cvs-server running on a linux-machine maybe called
linuxserv.
I'm getting acces to the cvs-server using pserver-method.
(The client =
is a WinNT machine and I use WinCVS.)
I'm sending loginfo mails on each commit. These mails get the sender =
mail-address "[EMAIL PROTECTED]".
Is it possible to send these mails with the sender =
"[EMAIL PROTECTED]"?
Where useronlinuxmachine and userinntdomain are the same user but =
different names.
For example:
The user "naujoks" in the nt-domain is user "dirk" on the
linuxserver =
the Message is sent with the sender "[EMAIL PROTECTED]"
but should =
be sent with "[EMAIL PROTECTED]".
***
The contents of, and the information contained in this email and any files transmitted
with it are confidential and legally privileged, and are sent for the personal
attention
of the addressee(s). If you are not the intended addressee, any use, disclosure or
copying of this document is unauthorised.
Thank you
NTL
***
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
sticky options
Hi What is or what are the sticky options of status command? tx a lot Paulo Bras _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rename atomicity
Paul Sander wrote: I can say from experience that assembling a sandbox from an unlocked repository is no more or less safe than any out-of-date sandbox, provided the CVS metadata are correct with respect to the contents of the working files. In either case, a "cvs update" is required (with the accompanying conflicts resolved) before a commit can be completed. This can be tricky if the read operation is done concurrently with a commit or tag operation. The first point, that the operation be read-only is absolutely correct. To resolve issues surrounding concurrent reads and writes, my method required that all revisions retrieved from the repository be identified in advance. What of the case where a file is being written while a read-only CVS attempts to read it. Providing RCS doesn't consistently break, and I'm far from sure it will, the resulting partial file in the sandbox will have valid metadata. If the file was touched in the sandbox, a later commit could check in garbage. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- I'm filling out the report right now. We haven't quite figured out if he committed suicide or died trying to escape. - Claude Rains as Captain Louis Renault, _Casablanca_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: can't login via pserver and therefore can't save ~/.cvspass file
Joe Kaiping wrote: Actually, I thought I would need to use both pserver and ssh. ssh for my personal CVS usage, and pserver for when CVS is executed only as a reader from within a script. (The script will be used to automatically update a web site with files contained in CVS) Can you tell me what is the best and/or most common way to call CVS from within a shell script so that the user running the script isn't required to type in a password? Or is there a way one might be able feed CVS the password from within the script? Set up an anonymous account with an empty password. If recent versions of CVS don't find an entry in ~/.cvspass, they'll try a login with an empty password: http://www.cvshome.org/docs/manual/cvs_2.html#SEC31 http://www.cvshome.org/docs/manual/cvs_2.html#SEC36 Alternatively, if you can't change the password on the read-only account for some reason, 'echo password |cvs login' should do the trick. I usually avoid that kind of thing for security reasons, but it would work. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- I will not do anything bad ever again. I will not do anything bad ever again. I will not do anything bad ever again... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
configuring mail-addresses
Thanks to all the answers.
Here a short description about how it works.
I hope the lines are now short enough.
I also beg your pardon if you think this is not the right
place for discussing this issue.
I managed to configure sendmail the way I wanted it to.
All the work is done with adding a line in the genericstable-file
in /etc/mail (for example "loginname[EMAIL PROTECTED]")
and then building the genericstable.db with the right maptype
in our situation hash using the makemap-command
("makemap -v hash genericstable.db genericstable").
Mit freundlichen Gren
i.A. Dirk Naujoks
-
Franke Siller Software GmbH
e-Mail: [EMAIL PROTECTED]
Tel.: 0211 9 24 95 120
-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rename atomicity
Derek R. Price writes: What of the case where a file is being written while a read-only CVS attempts to read it. Providing RCS doesn't consistently break, and I'm far from sure it will, the resulting partial file in the sandbox will have valid metadata. If the file was touched in the sandbox, a later commit could check in garbage. That can't happen. When rewriting foo,v, both CVS and RCS actually write a new file named ,foo, and only rename it to foo,v once it's been completely written successfully. If the rename happens while a reader has the file open, it will continue to read the original file (which will be deleted once the reader closes it). -Larry Jones There's a connection here, I just know it. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sticky options
Paulo Bras writes: What is or what are the sticky options of status command? You mean in the output? It's the keyword expansion mode (-k) for the file if it's other than the default. -Larry Jones I sure wish I could get my hands on some REAL dynamite. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: NEWBIE -- needs help in moving directories from one repositor
Luna, Glen writes: I did notice that the only files that seem to change is the val-tags and the history files. Will I have to merge these files or does it matter if I just keep things as they are in our CVSROOT? How important are these two files? Neither of them affect the correct operation of CVS. The val-tags file is a cache of valid tags that is used to determine that a tag is valid quickly rather than having to look through a bunch of files. If a tag isn't found in the file, CVS goes and looks through the files and, if it finds the tag, adds it to the file to save having to do that again next time. So, you could delete the file completely and CVS would continue to work just fine and gradually recreate it. The history file just supports the history command (see http://www.cvshome.org/docs/manual/cvs_16.html#SEC134); if you don't care about that, there's no need to merge the files. If you do want to preserve that history, I think you can just concatenate the two files. -Larry Jones Things are never quite as scary when you've got a best friend. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: why does wincvs show all files as modified
Sascha, I'm having a similar problem, but I am under the impression that it is related to an incompatibility between cygwin's cvs.exe and WinCVS, the problem being related to the timestamps the these two application formulate. However, early on the the diagnosis of my problem, David (sorry, don't know your last name) sent me a patched WinCVS cvs.exe. Maybe it is applicable to the problem you are reporting. (You aren't using cygwin cvs.exe, are you?). David, Do you have any patches for the timestamp problem that are applicable to WinCVS users that aren't using cygwin cvs.exe? Anyone, Would anyone care to comment on the joint use of cygwin cvs.exe and WinCVS - whether it is advisable, what to watch out for, how to configure the two systems to make sure they are compatible, etc. On the one hand, I am tempted to advise against their joint use. There is this problem with false locally modified flags and at least a couple of problems related to linefeeds. On the other hand, I'm wondering if a proper solution to the problem is to point one's cygwin PATH to the WinCVS version of cvs.exe. Can anyone see a problem with this approach. Chuck -Original Message- From: sascha.drews [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 11, 2001 10:25 AM To: info-cvs Subject: why does wincvs show all files as modified hello everybody out there. i have installed an cvs-server on nt (latest version of cvsnt) and a client (also nt) using wincvs1.2. connecting is no problem, import of a module (from the wincvs-client) also seems to cause no errors (*CVS exited normally with code 0*). but when i checkout this module (no error-message from cvs, too) wincvs displays each file as "mod. file" with an red icon. what am i doing wrong? there was similar problem discussed in this mailinglist some days before, where the solution was to uninstall wincvs and delete all registry-entries belonging to wincvs. i did this a couple of times (including reboot of the system), but no chance... i hope, there's somebody to help me... MfG Sascha Drews Team ERIS Mercoline GmbH Tel. +49 (0)30 4393 - 3048 Mail [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
merge a branch which contains a name-changed file
Hi, On a specifie branch, I change a file's name from "old" to "new" (the file content is also changed). Next I am going to merge the branch into the HEAD. I hope to see the file "old" is replaced with "new" in the HEAD after the merge. Can I see it? ( I guess the case is: both files exist, and I have to remove the file "old" from HEAD) Thank you -S. Chen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge a branch which contains a name-changed file
Susie writes: On a specifie branch, I change a file's name from "old" to "new" (the file content is also changed). Next I am going to merge the branch into the HEAD. I hope to see the file "old" is replaced with "new" in the HEAD after the merge. Can I see it? ( I guess the case is: both files exist, and I have to remove the file "old" from HEAD) Assuming you did the rename by removing the old name and adding the new name and then committing those changes, the merge should try to remove the old name and add the new name. (But removing the old name will fail if there were changes on the trunk after the branchpoint which you will have to merge into the new file manually.) -Larry Jones I'm a genius. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Can the -D option be used on a branch?
David L. Martin writes: I'd like to be able to checkout from a branch but take revisions that are older than a specified date. Since the -D and -r are both sticky, they apparently cannot be used in combination. Does anyone know of a workaround or combination of commands to do this? Actually, they can be used in combination. -Larry Jones It's a Doofus Ignoramus! Our hero slowly reaches for his stun blaster! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rename atomicity
Paul Sander wrote: Have you looked into the way that RCS works? It does not replace the RCS files in-place; it makes a modified copy in its lock file, and then renames the lock file on top of the original. Yeah, I knew that. Thanks. I've used this method with great success for years, with concurrent commits, under the conditions you state. There have been no corruptions of any sandbox to date. How do you accomplish this? Do you have a patch? Does anyone know what happens if you put '-n' on the cvspserver line in inetd.conf? Sounds neat, but I suppose this might not do the trick for a repo on a local CD-ROM. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- 116. (A)bort, (R)etry, (P)retend this never happened... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rename atomicity
I use RCS directly on the repository via a network filesystem. --- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: Have you looked into the way that RCS works? It does not replace the RCS files in-place; it makes a modified copy in its lock file, and then renames the lock file on top of the original. Yeah, I knew that. Thanks. I've used this method with great success for years, with concurrent commits, under the conditions you state. There have been no corruptions of any sandbox to date. How do you accomplish this? Do you have a patch? Does anyone know what happens if you put '-n' on the cvspserver line in inetd.conf? Sounds neat, but I suppose this might not do the trick for a repo on a local CD-ROM. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rename atomicity
Paul Sander writes: I use RCS directly on the repository via a network filesystem. Just for posterity, let me note that using RCS to *read* a CVS repository is completely safe, but using RCS to *write* to a CVS repository is dangerous because they don't honor each other's locking schemes. -Larry Jones OK, what's the NEXT amendment say? I know it's in here someplace. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS bashing?
Someone brought up a site on another mailing list about CVS and its limitations and was citing this as a reason to not use CVS...what do you all think about this? Some of this stuff I have personally witmessed (i.e. large binary file problem, no directory versioning) but I'm curious as to others opinions... http://www.snuffybear.com/scm_grind_cvs.htm Gary [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rename atomicity
On Wed, Apr 11, 2001 at 10:11:18AM -0700, Paul Sander wrote: Due to the way that the filesystem works, if the original is open for reading at the time of the rename, it remains open with the old data, and gets removed when it's closed. So the sandbox gets the correct data. There's a WinNT/2000 server now, isn't there? (I wouldn't use it unless forced, and I haven't been forced, so I haven't bothered keeping up :-) What are Windows's rename semantics? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS bashing?
There are obviously some areas where CVS can be improved - no doubt. But if you compare it to some other commercial SCM system that I'm familiar with, e.g. ENVY that comes with IBM's Visual Age for Java or PVCS, it is much, much superior. If ClearCase were free I'm pretty sure that I would choose it over CVS, but it's anything buy free. The Subversion project is interesting, but they will no doubt barrow a lot from CVS, if not code, then at least design and functionality. The bottom line is that you can do a lot, lot worse than CVS, even if you choose a commercial tool. My two cents... Chuck -Original Message- From: gary.heuston [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 11, 2001 1:04 PM To: info-cvs Subject: CVS bashing? Someone brought up a site on another mailing list about CVS and its limitations and was citing this as a reason to not use CVS...what do you all think about this? Some of this stuff I have personally witmessed (i.e. large binary file problem, no directory versioning) but I'm curious as to others opinions... http://www.snuffybear.com/scm_grind_cvs.htm Gary [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS bashing?
On Wed, Apr 11, 2001 at 01:04:28PM -0500, Gary Heuston wrote: Someone brought up a site on another mailing list about CVS and its limitations and was citing this as a reason to not use CVS...what do you all think about this? Some of this stuff I have personally witmessed (i.e. large binary file problem, no directory versioning) but I'm curious as to others opinions... Yeah, most of his technical points are pretty valid: CVS does not provide Tree/Dir versioning Support for attaching File Project Meta Data is weak Activities like file renaming are not naturally supported I don't think there'll be much argument about these. He mentions Subversion (http://subversion.tigris.org/index.html). I'm keeping an eye on that too, for all of the above reasons; it looks promising. Bitkeeper (http://www.bitkeeper.com/) has also been mentioned, but it's only semifree. CVS stability can be flaky at times (large binaries) I haven't experienced any flakiness -- at least not with recent versions; it was worse in the past. But then, I haven't put any large binaries into CVS, so I wouldn't know about that. Judging by recent list traffic, though, sure the repo gets big (they don't "diff" very well). Not sure what's "flaky" about it, unless you don't have enough /tmp space (which is arguably a sysadmin problem, not CVS's fault). It's hard to tell whether he means it's flaky specifically with large binaries, or whether they're merely one example. If the former, he may have a point. If the latter, I'd say it's at best an unfair generalization. Merging is very primitive Hmmm. How could it be better? NOT a rhetorical question; I'd really like to know. (I haven't used the commercial ones he's comparing CVS to.) And finally, If you want an answer fast, you can?t rely (or blame) the vendor Not a technical problem. Subversion won't be able to solve it either. Re lack of directory versioning, he says: (This in my opinion is unacceptable) Well, he's right; that is an opinion. Others' opinions differ. The binary-file thing is questionable IMO, and I can't evaluate the merging issue. The rest, though, are indeed valid reasons not to use CVS. Of course there are lots of valid reasons *to* use CVS. As always, it comes down to a tradeoff. That CVS is free software can be either a plus or a minus, it seems to me, depending on one's situation. The standard open-source vs. proprietary debate. (We've all seen it ad nauseum, so lets not go there again now, ok?) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
'rcsinfo' template question
Is there a way to have the commit message editor NOT insert a blank line above my 'rcsinfo' template? I just want to have a template that looks like: BUG#/Activity: inspector: comments: It works fine now, except for the annoying blank line that is inserted at the beginning. Thanks, Vic -- --- * Vic Gedris * vgedris @ atreus-systems . com * --- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs.cvshome.org down temporarily
The main CVS repository is down while we switch the DNS records to point at its new location. It should be up again within the hour. Thanks for your patience. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- I will not burp in class. I will not burp in class. I will not burp in class... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS bashing?
On Wed, Apr 11, 2001 at 04:44:49PM -0400, Eric Siegerman wrote: Merging is very primitive Hmmm. How could it be better? NOT a rhetorical question; I'd really like to know. (I haven't used the commercial ones he's comparing CVS to.) I've recently started working at a perforce shop. One thing that perforce does with it's merging is, instead of doing a default merge, it gives you options: Keep your changes only, keep the other set of changes only, or merge the changes. Granted, in my experience, 99% of the time you want to merge the changes. But every once in a while, you don't. (and it's usually not determined by a file type so you can't use cvswrappers to control it). Otherwise, I've not been convinced that things like changesets where you pick and choose which bits and pieces get included into a particular source file (ala clearcase) is worth it. Just the administrative overhead would be obnoxious! :- One place I would like to see improvements is the ability to automatically be able to track how branches were synced up together so that changes aren't reapplied. Yes, this can be done easily with scripts. But having to write scripts portable to various environments is a bit of a pain (ie, making sure everyone has perl on their machines, or writing tools in Bourne and batch, and so forth). It's a tough selling point at times to say "Yes, we can easily work around that limitation, but we'll have to write a couple of extra tools." (Ignoring the fact that no matter what SCM tool we use, we're still going to have to write our own wrappers around it.) mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 'rcsinfo' template question
Vic Gedris writes: Is there a way to have the commit message editor NOT insert a blank line above my 'rcsinfo' template? Apparently not. Does anyone know why the blank line is there? (It would be easy enough to change the code to get rid of it.) -Larry Jones The authorities are trying to silence any view contrary to their own! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge a branch which contains a name-changed file
One more thing. I have another branch B which is forked off the HEAD before the merge (i.e. B still contains the file with old name). If the merge removes old name and add the new name, what will happen to the file when I merge B into HEAD? Your help is very valuable to me : -Susie - Original Message - From: "Larry Jones" [EMAIL PROTECTED] To: "Susie" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, April 11, 2001 10:21 AM Subject: Re: merge a branch which contains a name-changed file Susie writes: On a specifie branch, I change a file's name from "old" to "new" (the file content is also changed). Next I am going to merge the branch into the HEAD. I hope to see the file "old" is replaced with "new" in the HEAD after the merge. Can I see it? ( I guess the case is: both files exist, and I have to remove the file "old" from HEAD) Assuming you did the rename by removing the old name and adding the new name and then committing those changes, the merge should try to remove the old name and add the new name. (But removing the old name will fail if there were changes on the trunk after the branchpoint which you will have to merge into the new file manually.) -Larry Jones I'm a genius. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS bashing?
On Wed, Apr 11, 2001 at 06:06:22PM -0400, Eric Siegerman wrote: On Wed, Apr 11, 2001 at 02:27:15PM -0700, Mike Castle wrote: I've recently started working at a perforce shop. One thing that perforce does with it's merging is, instead of doing a default merge, it gives you options: Keep your changes only, keep the other set of changes only, or merge the changes. Not too hard to do in CVS once you know how. Granted, you have to take those steps *before* typing "cvs update"; it doesn't stop to ask you. (No, I'm not suggesting it should!) Oh, true. delete your file, or keep a backup copy of it before hand. But sometimes, if you know there is going to be this type of issue, that cvs would stop to ask you. But as I said, it's rare that you actually need that function, and probably not worth trying to code in. :- mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS bashing?
From: Mike Castle [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 11, 2001 2:27 PM I've recently started working at a perforce shop. One thing that perforce I worked with perforce for a while, and there are a couple of other things I miss, besides the merge options. o Atomic changes. It's like every commit is a tag of its own. If you check in two files at once, where the modifications in one will cause an error without the modifications in the other, those modifications are forever associated with each other. A "commit", or in perforce terminology a change, has associated with it all of the modifications to all of the files in the commit, a time stamp, and a comment. In cvs, these things go into individual files, but they aren't tied together anywhere. It's very useful to be able to say, "Give me this project as it was when change 999 was checked in." o Mapping any file in the repository to any location in your workspace, with wildcard matching. Yeah, you can shoot yourself in the foot with this. o More things you can do with merging. In cvs, you can merge in changes you've made in your workspace, or you can merge changes from branches of the same code line. In Perforce, you can merge seemingly unrelated files. (Say you make a change to one Makefile, and you'd like to make the same change in another Makefile in a different directory.) One way to "rename" a file is to "merge" or "integrate" it to a different file name which didn't exist before. o Perforce remembers merges. Seems like there was something else, but it slipped my mind while I was typing. Anyway, it's pretty cool. Not to say that cvs isn't cool in its own way. Jerry ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
speaking of /tmp....
In my /tmp directory (Linux), there is a /cvs-serv4584 directory with various other directories that appear to at least partly duplicate portions of one of the subdirectories in my repository. The files in there now are about 5 days old, and take up about 11Mb. How are these directories/files used by CVS? Shouldn't they have been deleted by CVS a long time ago? How can I know if it is safe to delete them? I am using CVS 1.11 on Linux 6.2 (server) and Windows (clients). - Dennis ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs.cvshome.org down temporarily
"Derek R. Price" wrote: The main CVS repository is down while we switch the DNS records to point at its new location. It should be up again within the hour. Thanks for your patience. Okay, it's back up again. Please let me know if there are any problems. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- I will not say "Springfield" just to get applause. I will not say "Springfield" just to get applause. I will not say "Springfield" just to get applause... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rename atomicity
Agreed, this only works for read-only operations, like the one that started this thread. --- Forwarded mail from [EMAIL PROTECTED] Paul Sander writes: I use RCS directly on the repository via a network filesystem. Just for posterity, let me note that using RCS to *read* a CVS repository is completely safe, but using RCS to *write* to a CVS repository is dangerous because they don't honor each other's locking schemes. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS bashing?
All of the points made in that page are right on. I can go on to say more: - The modules database isn't versioned, which can affect reproducibility requirements. - The *info files accept a comprehensive list of sources on their command lines, limiting their scalability. (After a branch merge on a very large project, the command line buffer of the shell invoking the *info file can overflow, causing breakage.) - Triggers registered via the modules database are sometimes persistent, causing suprises after modifications. - The history file grows without bound, and can't be managed in any natural way. I'm sure I can go on if I think about this for a few minutes... --- Forwarded mail from [EMAIL PROTECTED] Someone brought up a site on another mailing list about CVS and its limitations and was citing this as a reason to not use CVS...what do you all think about this? Some of this stuff I have personally witmessed (i.e. large binary file problem, no directory versioning) but I'm curious as to others opinions... http://www.snuffybear.com/scm_grind_cvs.htm --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS bashing?
BTW, there's now a stripped-down version of ClearCase, suitable for for small workgroups, for a much cheaper price. It's called ClearCase LT, and you can get more info on it from http://www.rational.com/products/clearcase/ . --- Forwarded mail from [EMAIL PROTECTED] There are obviously some areas where CVS can be improved - no doubt. But if you compare it to some other commercial SCM system that I'm familiar with, e.g. ENVY that comes with IBM's Visual Age for Java or PVCS, it is much, much superior. If ClearCase were free I'm pretty sure that I would choose it over CVS, but it's anything buy free. The Subversion project is interesting, but they will no doubt barrow a lot from CVS, if not code, then at least design and functionality. The bottom line is that you can do a lot, lot worse than CVS, even if you choose a commercial tool. My two cents... --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS bashing?
On Wed, Apr 11, 2001 at 05:21:26PM -0700, Paul Sander wrote: - The modules database isn't versioned, which can affect reproducibility requirements. This same problem exists with Perforce and it's concepts of 'views' (think each user has their own modules files). What we do is, instead of managing views (or modules) is copy code from the primary source into the heirarchy of the product, and then use it there. It's made read-only, and any changes that need to get made are done in the primary source tree only. (Changes will be automatically propogated out via use of triggers). This process should work with CVS as well. - The *info files accept a comprehensive list of sources on their command lines, limiting their scalability. (After a branch merge on a very large project, the command line buffer of the shell invoking the *info file can overflow, causing breakage.) I thought all of the *info files worked on subdirectory level only. You have enough files in a single directory to cause an overflow? :- This sounds like it could be somewhat easy to fix. Do something xargish inside of cvs to call them multiple times. - The history file grows without bound, and can't be managed in any natural way. A logrotate type of program can't work against history? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: speaking of /tmp....
Thanks Larry. The process was no longer running, but I don't remember anything wierd happening at the time the files were created, so I'm not sure why the directory was left hanging around. I deleted the directory and everything seems fine. - Dennis - Original Message - From: "Larry Jones" [EMAIL PROTECTED] To: "Dennis Jones" [EMAIL PROTECTED] Cc: "CVS Mailing List" [EMAIL PROTECTED] Sent: Wednesday, April 11, 2001 9:04 PM Subject: Re: speaking of /tmp Dennis Jones writes: In my /tmp directory (Linux), there is a /cvs-serv4584 directory with various other directories that appear to at least partly duplicate portions of one of the subdirectories in my repository. The files in there now are about 5 days old, and take up about 11Mb. How are these directories/files used by CVS? Shouldn't they have been deleted by CVS a long time ago? How can I know if it is safe to delete them? In client/server CVS, the server creates a mirror of the (relevant parts of the) client's working directory -- that's what you're looking at. In particular, the CVS server with a pid of 4584 is who created that directory and it should have deleted it when it was finished. If that server process is no longer running, then it's safe to delete the directory; the server either crashed or encountered a serious error and didn't delete it's working directory in order to aid in troubleshooting the problem. If that server process is still running, then that's a problem in and of itself. -Larry Jones Something COULD happen today. And if anything DOES, by golly, I'm going to be ready for it! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: why does wincvs show all files as modified
Chuck, The patch I submitted for incorporation to WinCVS should show up in the next release (1.2.1 perhaps). The specific issue addressed was the difference in date/time stamp for days of the month from the first through the nineth for Unix/cygwin versus Visual C++ (WinCVS). The bug should crop up only if you are mixing clients accessing the same cvs working area. The fix adopts a standard string format for date which uses a leading space, not a 0 (e.g. Apr 9, not Apr 09), as prescribed by the Standard C Library. I have not used cvsnt, so I can't say whether this is the same problem. If Sascha were to update her working area now (since we're past the single-digit April dates) yet the Mod file indication persists, then this is not the same problem. I would then suspect a daylight saving time transition bug (if it was working before 4/1/2001). David Martin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, April 11, 2001 11:43 AM Subject: RE: why does wincvs show all files as modified Sascha, I'm having a similar problem, but I am under the impression that it is related to an incompatibility between cygwin's cvs.exe and WinCVS, the problem being related to the timestamps the these two application formulate. However, early on the the diagnosis of my problem, David (sorry, don't know your last name) sent me a patched WinCVS cvs.exe. Maybe it is applicable to the problem you are reporting. (You aren't using cygwin cvs.exe, are you?). David, Do you have any patches for the timestamp problem that are applicable to WinCVS users that aren't using cygwin cvs.exe? Anyone, Would anyone care to comment on the joint use of cygwin cvs.exe and WinCVS - whether it is advisable, what to watch out for, how to configure the two systems to make sure they are compatible, etc. On the one hand, I am tempted to advise against their joint use. There is this problem with false locally modified flags and at least a couple of problems related to linefeeds. On the other hand, I'm wondering if a proper solution to the problem is to point one's cygwin PATH to the WinCVS version of cvs.exe. Can anyone see a problem with this approach. Chuck -Original Message- From: sascha.drews [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 11, 2001 10:25 AM To: info-cvs Subject: why does wincvs show all files as modified hello everybody out there. i have installed an cvs-server on nt (latest version of cvsnt) and a client (also nt) using wincvs1.2. connecting is no problem, import of a module (from the wincvs-client) also seems to cause no errors (*CVS exited normally with code 0*). but when i checkout this module (no error-message from cvs, too) wincvs displays each file as "mod. file" with an red icon. what am i doing wrong? there was similar problem discussed in this mailinglist some days before, where the solution was to uninstall wincvs and delete all registry-entries belonging to wincvs. i did this a couple of times (including reboot of the system), but no chance... i hope, there's somebody to help me... MfG Sascha Drews Team ERIS Mercoline GmbH Tel. +49 (0)30 4393 - 3048 Mail [EMAIL PROTECTED] ___ 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: Can the -D option be used on a branch?
David L. Martin writes: I'd like to be able to checkout from a branch but take revisions that are older than a specified date. Since the -D and -r are both sticky, they apparently cannot be used in combination. Does anyone know of a workaround or combination of commands to do this? Actually, they can be used in combination. -Larry Jones Ah yes, so they can! The tag is sticky, not the date, in the resulting checkout, but the date option is honored as expected. The command usage for checkout and update (cvs --help co, cvs --help up) should perhaps be changed from [-r rev | -D date] to [-r rev] [-D date] to indicate that both options may be used in combination. In contrast, I note that rtag and tag operations do not accept the combination of -r and -D options. They are mutually exclusive, and the help for rtag and tag indicates this ([-r rev | -D date]). It would be nice for tag/rtag to accept both options as well. (But one could always tag following checkout with both options and achieve essentially the same result). Thanks, David Martin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
