Re: Bug with entering Log messages using editor other than vi
On Mon, Mar 08, 2004 at 06:06:44PM -0800, g murkumar wrote: $cvs commit the cvs would open a gvim editor window. AND at the same time say log message empty or unmodified: a)abort c)continue e)edit !)use same message for all directories The problem is that gvim forks and runs in the background -- when you type gvim at the shell, you get another shell prompt immediately, as opposed to command-line vim, in which you don't get another shell prompt until you've quit the editor. But CVS needs its $EDITOR to run in the foreground; when the editor process exits, CVS knows it's time to read in the log message. Try setting EDITOR to gvim -f. That tells gvim to run in the foreground, which should make CVS happy. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: EOF while looking for end of string in RCS file : How to delete problem file?
On Tue, Mar 09, 2004 at 04:27:39AM -0800, Fred Phase wrote: I imported some MP3s into CVS by mistake [and can't cvs delete one of them because the ,v is corrupt] Just go directly into the repo and delete the ,v file. CVS is fine with that. The next time you do a cvs update in your sandbox, it'll print a message and delete the working file from your sandbox -- so make sure that's not your only copy of the file! Be aware that doing this will throw away the file's revision history, old tags, commit logs, etc. I heard that doing stuff directly in the CVSROOT directory is most inadvisable and could break stuff if I am no careful. This is almost always very true, but you've stumbled on a rare exception. Other things you might do directly in the repo (e.g. moving files into or out of the Attic, messing with tags, and such) could indeed break CVS if done without regard to the way CVS does things. Deleting ,v files outright doesn't break CVS; as I said, CVS recovers just fine on the next update. Even so, it's a practice that's usually advised against in the strongest terms, because it trashes all the history that's the main reason for using a revision-control system in the first place! In your case, though, you seem to be saying that the file should never have been put into CVS at all; if that's correct, the file's revision history is presumably unimportant enough to you that you won't mind sacrificing it. (If I'm wrong about that, ask again and we can try to work something else out.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvswrappers and import command line conflict???
On Wed, Mar 03, 2004 at 09:43:56AM -0500, Larry Jones wrote: I don't think so -- have you tried it? Woops, you're right! I knew I'd accomplished it; shame on me for describing how from (what turned out to be completely fictional and bogus) memory. What I *actually* did (and this time I have verified it) was to put this line at the bottom of my ~/.cvswrappers: * -k 'o' -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvswrappers and import command line conflict???
On Tue, Mar 02, 2004 at 09:23:43AM -0500, Timothy Stone wrote: $ cvs -d $REP import -ko -I! -m some meaningful message blojsom BLOJSOM REL_2_11 Basically, the -ko switch seems to be hosing the JAR files in the project. Everything gets a Sticky Option of -ko. This kills JARs. Yup. The -ko on the command line overrides the -kb in cvswrappers. Try putting -ko in your ~/.cvsrc (look up the syntax in the manual); then don't specify any -k variant on the command line. That way it'll be the -kb in cvswrappers that takes precedence. (No comment on your -W approach; I've never tried it, so I have to take your word for it that it doesn't work.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [Maybe Spam] Re: [OFT] scripting removal of $Id:
On Fri, Feb 20, 2004 at 04:49:31PM -, Euan Guttridge wrote: Thanks but the exercise is too strip out the [CVS-keyword] line completely - reason being to minimise unnecessarily checking of code 'conflicts' while merging with eclipse. You could roll your own with something like (untested): $ perl -I.bak -p e 's/\$Id:[^$]*\$//' [files...] But look again at the -kk suggestion; it might do what you want. If you merge with -kk, then instead of: $Id: stuff $ you'll get precisely the string: $Id$ in each of the revisions used as inputs to the merge. Since it's the same line in all three files, there should be no merge conflict. Note, though, that as a side effect, merging with -kk will stickily set all the files in your sandbox to -kk mode. *After* you commit the merge, you'll have to do a cvs up -A to restore them. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Branch Tag Deleted, Can it be Re-created?
On Fri, Feb 20, 2004 at 10:51:35AM -0800, Jenny Lowe wrote: I thought the following command would work: cvs rtag -b -r nbTag branch10 but it does nothing other than print the cvs rtag help options. Try: cvs tag -b -r nbTag branch10 (tag, not rtag), or: cvs rtag -b -r nbTag branch10 module-name -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Branch Tag Deleted, Can it be Re-created?
On Fri, Feb 20, 2004 at 12:10:41PM -0800, Jenny Lowe wrote: That created me a whole new branch. For instance, one of the mainline files is revision 1.65. I had a branch created at 1.65.2 (the branch tag was deleted) then with the tag command from below, it created 1.65.4. I want to re-create my branch tag at 1.65.2. Oops! Sorry. See this message: http://mail.gnu.org/archive/html/info-cvs/2001-12/msg00599.html In which, among other things, we learn that I started with the same wrong suggestion then too. Duh! -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: how to support symlinks?
Ok, you've got me curious. On Wed, Feb 18, 2004 at 04:06:29PM -0500, Robert P. J. Day wrote: [...] a utility i read about in a 3-year-old posting called symlinks that uses a .symlinks file in each directory that will contain symlinks. This seems to be the original reference to it: http://www.gnu.org/server/standards/README.html#SEC01 Reading between the lines, I infer that the symlinks program was developed as an internal utility for the GNU web site. Perhaps it was never formally released to the public. That seems a bit surprising, for the FSF of all people, but it's not actually contrary to the GPL :-) Maybe the program was never deemed to be of release quality. Clues: - The wording, a simple mechanism has been implemented on the machine hosting the www.gnu.org, suggests a quick-and-dirty local utility - The file's location is given as: gnudist.gnu.org:/usr/local/src/symlinks-1.1.tar.gz which is an rcp-style pathname, not a URL - The directory part of that location is /usr/local/src, not a directory one usually finds in anon-ftp areas -- and certainly not one I recall ever seeing on ftp.gnu.org (which has the same IP address as gnudist, btw) Try asking the GNU webmasters, or other individuals who've discussed the thing in the past. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Possible race in pserver leading to broken pipe error?
On Tue, Feb 10, 2004 at 07:23:43PM -0500, Derek Robert Price wrote: Larry Jones wrote: fflush()/close() is a no-no -- you want fclose() instead. I couldn't find a man page for a file descriptor flush - There isn't one, especially not for pipes. AFAIK, as soon as you've written data into a pipe with write(), it's immediately available for read() without further (necessary or possible) action on your part. (For regular files there's fsync(), as already mentioned, but that's sort of different, in that the flushing it does is transparent to user processes under all normal circumstances; for sockets there's shutdown(), which looks sort of half-way between a flush and a close.) is there some way I could have flushed the pipe without attaching the stream? You mean protocol_pipe? It shouldn't be necessary. The buffer that fflush() flushes is only created by fdopen(), so the combination is a no-op. stdout and stderr, on the other hand, were already streamified, and presumably had data written to those streams, so those *do* need to be flushed -- but see below. All I think Larry's saying is, use 'fflush ... fclose' instead of 'fflush ... close'. The former sequence gives the userland stdio layer a chance to clean up everything it needs to clean up, whereas the latter sequence assumes that stdio has no cleanup to do in the first place. That might well be a correct assumption on many systems, but it's probably unsafe to count on it. In fact, I believe you could get away with just fclose()'s, with no fflush()'s at all. close() without fflush(), on the other hand, you know about... That is: fclose(stderr); fclose(stdout); close(protocol_pipe[1]); Two other comments: - Typo in the comment for set_block_fd() -- s/non-// * Set buffer FD to non-blocking I/O. Returns 0 for success or errno * code. - Maybe I'm being overly pedantic, but the last bit of new code, which drains flowcontrol_pipe, only does so if it succeeds in setting the descriptor to blocking mode. If that attempt fails, you could drain the pipe anyway; it'd be a busywait loop, but that seems safer than doing nothing. Something like this (untested): char junk; ssize_t status; while ((status=read (flowcontrol_pipe[0], junk, 1)) 0 || (status == -1 errno == EAGAIN)); -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Is there a cvs uncommit, or somethings similar
On Wed, Jan 07, 2004 at 01:35:20PM -0500, Schoep, Grant @ STORM wrote: I just accidently checked a number of files in that I did not want to. I know I could just get the old version, and check that in overtop of the incorrect one. That's the approach that's usually recommended. (The easy way to get the old version is: cvs update -jwrong-version -jprevious-version file Note that the higher-numbered revision is named *first*.) But I really would like to just undo it, as the cvs log descriptions on these files is screwed up. cvs admin -orev file will delete revision rev, but that's frowned on. The intent of a revision history is to be append-only. Besides that philosophical problem, it seems to me that odd things might happen if one deletes revisions from a repository that's actually shared (I've done it on my own private repo's without any problems; just remember to do cvs update right afterward, since if you delete the revision that your sandbox is updated to, cvs admin -o does *not* fix up your sandbox). But if the bad revisions' content is ok, and it's just the log messages you're concerned about, your best bet is to use: cvs admin -mrev:newmsg file to fix the messages. I'd rather not go in a manually muck with the ,v file in the repository. No kidding! -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checksum failure: serious problem or not?
On Mon, Dec 22, 2003 at 09:45:00PM -0800, Mark D. Baushke wrote: In theory, the server had a copy of the client file to do the patch in the first place and the client copy either became stale or was corrupted while the server copy was being used to generate a patch. Or the client file changed but its timestamp did not. In a sandbox in which file foo needs to be updated (U status from cvs -nq update): $ cp -p foo foo.stamp $ vi foo# make some changes $ touch -r foo.stamp foo $ cvs ci foo If it's a remote sandbox, that provokes the checksum error followed by a full fetch; whether the sandbox is remote or local, the user's changes are irrecoverably lost. (I don't know how that situation might occur in real usage; I did it artificially while researching my previous message in this thread :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checksum failure: serious problem or not?
On Fri, Dec 19, 2003 at 03:22:31PM -0500, Larry Jones wrote: Larry Eric Siegerman writes: Larry Larry The P status and the checksum failure message should both go Larry away. (Patched and fully-refetched files should all be labelled Larry U.) Larry Larry I might be convinced about P status (although, personally, I like it), Hmm, what would it take to convince you? :-) My main arguments are: - User confusion; it's a fairly FAQ, and a needless one - The fact that CVS distinguishes P from U implies (wrongly) that they're different in some important source-controlish way -- commensurate with, say, the distinction between U and M, or between M and C, or between A and ?. In fact, as far as source control is concerned, P and U are identical. In other words, there's a layer mismatch. The other codes all reflect differences at the source-control layer (to rather stretch the OSI model) but P is different from U only at a lower layer. I believe it's this mismatch that's the cause of all that user confusion. Larry but I strongly disagree about the checksum failure message. It Larry indicates a serious confusion about the state of the working file that Larry the user *must* investigate. It indicates that there were local changes Larry to the file that CVS doesn't know about and is in the process of Larry discarding. Unless you like losing changes, you must figure out what Larry happened to get you into that state and ensure that it doesn't happen Larry again in the future. On Fri, Dec 19, 2003 at 04:45:54PM -0500, Jim.Hyslop wrote: Jim Well, there's a couple of problems with that. First of all, the error Jim message does not say anything like that - the message is quite terse and Jim most users wouldn't know to check their files. Second, by the time the Jim operation completes, any trace of the original file is gone, so it's almost Jim impossible to investigate exactly what changed - or what CVS _thought_ had Jim changed. The original file is not backed up. Jim Jim So, I think CVS should be modified either to: Jim 1) eliminate the checksum failure message, or Jim 2) modify the error message to make it clearer what happened, and rename the Jim original file to .#whatever. I strongly agree with Jim. Some more thoughts on how it could be improved: - Saving the user's file as .# backup is the least it should do. Better would be to abort the update, leaving the user's file unchanged. - Best of all would be to fall back to a merge instead of to the current overwrite. This wins because it reduces the case to one the user is already familiar with -- saving the .# file falls out transparently (from the user's point of view; I don't know about the code's), and the error message can probably be eliminated after all. - Local mode should offer the same level of protection as does client/server. (Even though the proximate reason that the error is detected in client/server (failed patch attempt) doesn't apply to local mode, the underlying error condition is just as severe, and just as worthy of action by either the user or by CVS.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS security audit?
Just out of curiosity, is this rash of CVS security fixes coming out of the savannah.gnu.org audit? Let me be a bit of a gadfly: I presume the Savannah folks are security-auditing CVS along with other relevent tools, even if they aren't the source of the current bug reports. Now, I seem to recall that one of the big objections to pserver is that CVS has never had a security audit. Once the Savannah audit is finished, that objection goes away. How will that affect peoples' level of confidence in pserver and the like? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS security audit?
[following up my own post; sorry] On Fri, Dec 19, 2003 at 06:08:40PM -0500, I wrote: How will [a security audit having been done] affect peoples' level of confidence in pserver and the like? In another thread, on Fri, Dec 19, 2003 at 11:18:57AM -0500, Jim.Hyslop wrote: Well, clearly pserver is not secure because the password is sent effectively in plain text [...] Woops, I'd forgotten about that! Ok, as regards pserver itself, my question was pretty dumb. But how about GSSAPI or Kerberos with encryption? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: automating cvs checkout/checkin and also don't checkin identical files
On Mon, Dec 15, 2003 at 09:20:45PM -0700, Chad Woolley wrote: I am looking for a way to automate a CVS checkout/checkin process. You'll have to explain a bit more what you mean, I think. Also, on the checkin, I don't want to check in any files that have identical contents to the repository version - even if they have been saved with a new timestamp. This is how CVS already works. If you're working client/server, CVS will tell you in its log-message-editor comments that the file is modified, but it won't actually check in a new revision. That little mislead happens because at the time CVS collects the log message, it knows which files have different timestamps, but doesn't yet know which subset of them also have different content. (It can't diff the files until it's sent the sandbox copy to the server (duh), and it can't do that until it has the log message, because it needs to send all data necessary for the commit to the server in one go, without any pauses for user interaction.) When operating locally, on the other hand, it can figure that out *before* collecting log messages, so it can display an accurate file list. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sticky non-branch tags are sometines treated as branches in empty
On Tue, Dec 09, 2003 at 04:06:49PM -0800, Alvaro Martinez Echevarria wrote: cvs -d WHATEVER co -r MYTAG parent/anotherparent/subdir [...] My question is, because I invoke the above commands from a wrapper, is it a valid and safe workaround to manually remove CVS/Tag files from [parent and parent/anotherparent] after running the checkouts? If you do that, then instead of generating random branches all over the place every time you try to add new files or directories, you'll simply generate random trunk revisions. Probably not what you want. Instead, rewrite those directories' CVS/Tag files to contain revision tags. That way, if a user tries to commit something in parent/anotherparent, they'll get a nasty error message. It's ugly, but at least it fails safe. The user can cvs update -l -rbranch to put the directory on the branch they really want it on, and try again. I'd be tempted to rewrite the revision tag itself, not just the what-kind-of-tag-am-i flag, to something obviously bogus like this_is_a_phony_tag-ask_a_guru_for_help. That way, a user who's seen this before will recognize the bogus tag name and know what the situation is. For users who are new to it, they won't know what's going on, but again it'll fail safe, this time on the human scale: the user will *know* he doesn't know what's going on, whereas a legitimate tag name in the error message might have fooled him into thinking he did know :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problems with uncommitted working directories, from homeand work.
On Tue, Dec 02, 2003 at 11:04:54AM -0700, Larry Lords wrote: I have a question on Jim's statement Private branches are never considered candidates for releases or for builds. The operative word is private. I have always understood that a company would always release from a private branch. No; from a *non*-private branch. Other than that detail, your description of a branch-based release process sounds bang on. CVS doesn't distinguish between private and non-private branches; from its point of view they're all just cvs tag -b branch branches. The only difference is in your intention in creating thebranch, and thus what you subsequently do with it; CVS doesn't know or care. Hence Jim's suggestion of a naming scheme so your team can keep all those different-purposed branches straight. (Vendor branches, which of course CVS does treat specially, don't come into this discussion at all.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update times
On Fri, Nov 14, 2003 at 01:55:55PM -0800, Richard Pfeiffer wrote: The project in question (Proj A) and one I'm using for comparison look like this: Proj A is half the size as Proj B, but did have more directories. I might have to find out just how many more. Proj A took 2m15s to checkout, Proj B took 10m30s. Proj A took 1m14s to update, Proj B to 1m20s. How long do the du -k commands take? (Make sure the data is *not* in the buffer cache.) The time for a du is proportional to total number of filesystem objects, not to directories specifically, but the numbers might still be interesting. So Proj B is twice the Kb, takes 5 times longer to checkout but updates in the same time as Proj A. I'd be interested to know counts of files and directories for both projects. Not sure what use all these numbers would be, but they couldn't hurt :-) I would just write it off to # of dirs, but users claim it was much faster last week. I'll have to check and see if they checked in a bunch of files all in seperate directories, etc. Hmm, it just occurs to me. How about changes on the client side? Could it be that the project-A people (but not the project-B people) installed some app on their Windows boxes that interacts badly with WinCVS? Or in the network? Is there a flaky hub in the project-A room, or is someone there downloading DVDs in the background and saturating their uplink? :-) Could indivdual file or directory sizes have any bearing? Sure, they could be confusing the issue. If project B has N large files, and project A has N small files, I'd expect to see something very roughly like you're seeing -- though the twice the KB, 5 times longer to check out part is mystifying. But that aside, I'd expect the update times to be similar (assuming, of course, that the sandboxes were already up to date). Unlike actually fetching updates, merely checking up-to-dateness isn't proportional to the file sizes. Does a checkout's locking structure differ from an update's locking structure? I wouldn't think so, but if that was true, I would think the co and update times would be proportional for these two projects. Didn't someone say that co locks the whole tree, but update only locks one directory at a time? I don't see how that would affect things, though. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problem checking in large files
On Fri, Nov 14, 2003 at 03:12:52PM -0500, Jim.Hyslop wrote: Does a cvs status on the file indicate any sticky options, in particular -kb? If not, then that's your problem. For the record, cvs log and cvs status can display different values for the -k setting. The former is the value stored in the ,v file. The latter is the sticky setting that's actually in use in your sandbox; it will override the former if they differ. I mention this because it fooled me several times until I learned to watch for it (and it still fools me on occasion, too late, or too early, in the day :-) You need to cvs remove the file and re-add it with the -kb option. Or: cvs admin -kb file # Change the setting in the ,v file cvs update -A file # Propagate the change to the sandbox # (yes, you do need the -A here) Then check in a good copy of the file -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update times
On Fri, Nov 14, 2003 at 12:27:01PM -0800, Richard Pfeiffer wrote: However, we have one project in this repository that now takes 1:58 to checkout and 1:29 to update. It used to update much faster; these 'slow' update times just started occuring. Two stabs in the dark: - Are you on a branch, with large files and/or many revisions between head of branch and head of trunk? Many operations in CVS take longer under such circumstances, because of the way revisions are stored in the ,v file (trunk as reverse deltas from the head; branches as forward deltas from the branch point. See rcsfile(5)). - Does your slow project have a much larger directory:file ratio than your other projects? If so, it could be that locking overhead is dominating the total update time in that project, whereas in your other projects it's the useful work of updating revisions that dominates. CVS's locking overhead is proportional to the number of directories (not files) being operated on. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problem checking in large files
On Fri, Nov 14, 2003 at 04:20:14PM -0500, Jim.Hyslop wrote: Eric Siegerman [mailto:[EMAIL PROTECTED] wrote: For the record, cvs log and cvs status can display different values for the -k setting. Thanks for the correction, I should have mentioned 'log' to begin with. Well, it was hardly a correction, since you were right :-) It was meant as a caution to the original questioner: if you were thinking of using 'log' instead of 'stat' -- or, more likely, doing so by force of habit -- don't. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
On Wed, Nov 05, 2003 at 09:24:06PM -0800, Jim wrote: I suppose someone could have abused the case sensitivity and used capital cases of file extensions as backups... 'main.c' backed by 'main.C' though this seems like a bad habit. Interesting choice of example :-) Doesn't the latter mean C++ on some systems? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: the Cederqvist, difficulty downloading .pdf
On Wed, Oct 29, 2003 at 12:12:18PM -0500, Terrence Enger wrote: http://ftp.cvshome.org/release/feature/cvs-1.12.2/cederqvist-1.12.2.pdf. - Acrobat reader complains There was an error opening this document.[...] Yup, I get the same complaint. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs performance questions
On Tue, Oct 21, 2003 at 02:10:46PM -0700, Richard Pfeiffer wrote: (some of the project directories in the repository are rather large, 357 Mb, etc) 1) If we have multiple users sharing the same userid, would that create any kind of locks, etc, that could hinder co/ci times? Locks are certainly created, and that will certainly affect co/ci times. But the fact that multiple users share the same userid is irrelevent. (The practice is usually recommended against for reasons of accountability, but it should have no impact on performance.) The overall size of the source tree being operated on will have an effect here. CVS's locking mechanism calls for creating directories and/or files under *every* directory in the repository that's to be visited, *not* just at the root of the subtree of interest. So locking overhead is O(N) on the number of directories in the subtree, not O(1). (But note that I said in the subtree. If you do a cvs co on a leaf directory, i.e. one containing only files, that'll be fast even if the repo as a whole has thousands of directories. Same if you do a cvs co -l on any directory; since it doesn't recurse, it doesn't have to lock the subdirectories.) Of course, as the number of simultaneous users goes up (whether or not they're sharing userids), the likelihood of their contending for the same directories, and thus having to wait for each others' locks, also goes up. 2) There is a great deal of branching taking place, and it has come to my attention that there are some old undeleted tags hanging around. Could enough of these cause a performance issue? Sure, but the value of enough is likely *huge* :-) Tags per se don't take up much space, or, I imagine, much processing time. Deleting old tags is unlikely to have a noticeable effect. (It can make cvs log output less cluttered, at the cost of losing information of course; but DON'T do it merely as a performance measure.) What's more likely to slow things down is performing operations on branches that: - were created many revisions ago - have many revisions on the branch Specifically, the longer the path (along the revision tree) from the revision you're working with to the one at the head of the trunk, the longer the operation will take. See rcsfile(5) for an explanation. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS refuses to remove (branch) tag
On Tue, Oct 14, 2003 at 12:49:13PM -0700, Mark Jaffe wrote: cvs tag: Not removing branch tag `cr-1577' from '/home/cvsroot/internetservices/Ecare/html/care/MICCcontactForm.html,v'. cvs -H tag says: -B Allows -F and -d to disturb branch tags. Use with extreme care. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
FWD: Announce: Cvs-Brancher 1.00
This came across another list I'm on, but it's clearly relevent to CVS :-) Some people might find it useful. I haven't tried it myself; it just looks intriguing. Here's a link to the overview file from its documentation: http://cvs.sourceforge.net/viewcvs.py/tgen/Cvs-Brancher/doc/OVERVIEW?rev=1.3view=auto - Forwarded message from Bryce Harrington [EMAIL PROTECTED] - Subject: [Templates] Announce: Cvs-Brancher 1.00 From: Bryce Harrington [EMAIL PROTECTED] Date: Fri, 10 Oct 2003 10:56:09 -0700 (PDT) To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Static websites have a number of advantages over dynamically built sites, but one of the disadvantages is being able to schedule deployment of new content at arbitrary times. Cvs-Brancher is designed to address this issue by making it straightforward to branch a CVS tree and schedule a merge and rebuild using 'at'. http://freshmeat.net/projects/cvsbrancher/ An example for use of this is for posting press releases and other assorted website changes at 5am west coast time, to co-incide with start of business east coast time. This was the primary motivation for writing it. The advantage of doing a branch/merge is that regular maintenance can go on while the scheduled release is assembled and tested. Cvs-Brancher provides options to control what actions it should take in case of merge errors. While intended for CVS-based websites that use a build tool such as ttree, it is implemented generically and may have non-web uses, such as deploying cfengine-based system config changes, etc. Bryce ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates - End forwarded message - -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS patch for unedit -e
On Thu, Oct 09, 2003 at 09:42:40AM +0200, Krzysztof GORBIEL wrote: I have also tried to point my browser to the link attached in one of replies (dated 2001) but I got message: Permission: User Not Found: Only members of this project have permission to view this page (you are not listed as a member of this project You could always join... If it's the main CVS project on cvshome.org, I believe anyone's allowed to join with read-only access. Approval is only required because the software they're using to host the site won't let them turn off that feature. In other words, if you're asking for read-only access, approval is required, but isn't too hard to get. At least, that's how it was when I joined a year or two ago; is it still the case? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: remote cvs access - recommendations
On Wed, Oct 08, 2003 at 10:59:37AM -0700, [EMAIL PROTECTED] wrote: but in general, someone who accesses cvs [via SSH] has system access. not only can my co-developer do things like cvs checkout and cvs commit, but he can also ssh into the machine and work at a remote shell. is there a way to give co-developers access to cvs WITHOUT giving them system level access? You can configure sshd to only allow one command, cvs. I'm not sure how to do that, but it's been discussed here in the last few days, so check the list archives. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS hangs on certain files
On Wed, Oct 08, 2003 at 12:14:17PM -0700, Kyle Adams wrote: Anyone have any idea where the problem might be? Not a clue :-( But here are some things you can try to get more info: - run the client with (global) -t to get a debugging trace - define the CVS_CLIENT_LOG environment variable, to get a complete dump of the network conversation These are for the canonical cvs program, but I'm guessing they'll work in CVSNT as well. Probably not in the other clients. See the manual for details on both of these. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: diff of multiple files between old versions
On Wed, Sep 17, 2003 at 10:37:35AM -0700, Steve deRosier wrote: So, when I know the two dates that I need to know, how do I find out what changed between them (keep in mind that I don't want to do a cvs diff on each and every file by hand, the directory structure the cvs gives me is large and convoluted)? You should be able to simply do: cvs -z3 diff -D 2003-01-15 -D 2003-01-17 . CVS will recursively diff the whole tree. Of course, if you *do* want to diff just some specific files, you can name them on the command line. What I'm currently doing is checking out dated versions in different directories and compiling and testing: mkdir cvs011503 cd cvs011503 cvs -z3 co -P -D 2003-01-15 . Then again, since you already have both versions checked out, with GNU diff you can do: diff -r cvs011503 cvs011703 (Some other diff's work recursively too, but some don't, and some sort-of-work. GNU diff I trust. In fact, I prefer it even over cvs diff for getting an overview of how a large tree changed, since it gives you the complete picture on one output stream -- cvs diff puts differences on stdout, but reports adds and deletes on stderr, and in a less-clear form at that.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: updated to 1.11.6 (from 1.11.2) now have problems on windows
On Tue, Sep 16, 2003 at 10:31:07PM -0400, Larry Jones wrote: Eric Siegerman [EMAIL PROTECTED] wrote: Instead, perhaps it should do something like: if the specified pathname, together with the usual other criteria (-r, -D, sticky attributes, etc.), selects more than one *revision*, complain. Don't hold your breath. Implementing this would require such significant changes to CVS that I'd be tempted to call it 2.x. Thanks for setting us straight. *sigh* The thought was nice while it lasted... -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: updated to 1.11.6 (from 1.11.2) now have problems on windows
On Thu, Sep 11, 2003 at 11:54:20AM -0700, Kevin Layer wrote: cvs [server aborted]: CHANGE-LOG,v is ambiguous; could mean CHANGE-LOG,v or change-log,v On Thu, Sep 11, 2003 at 01:05:13PM -0700, Kevin Layer wrote: Lots of instances of the following in my repository: foo,v Attic/Foo,v where the Attic file was cvs rm'd years ago and is not used anymore. If I rename Attic/Foo,v to Attic/Foo_renamed_due_to_cvs_bug,v and cvs update -d on my Windows box, all is well. More or less shooting from the hip here, since I haven't checked the code: a more sophisticated is ambiguous test might solve this. What does ambiguous really mean here? I think it should mean, you're asking me to check out two revisions into the same file in the sandbox. In Kevin's situation, if a Windows user types cvs update -A foo (or cvs update -A FOO, or whatever), that will select a live revision from foo,v, but only a dead one from Attic/Foo,v, so it's not really a problem in practice. Similarly, if tag OLD_TAG was applied before the case-renaming was done, cvs update -r OLD_TAG foo would select only a revision from Attic/Foo,v since the tag won't exist in foo,v -- again not a problem. It's only if the user types something that matches a (non-dead) revision in each file, that there's a collision, e.g. cvs update -r1.3 foo when both foo,v and Attic/Foo,v happen to contain live 1.3 revisions. I'm guessing that what the is ambiguous test does now is, if the specified pathname selects more than one file in the repo, complain. Instead, perhaps it should do something like: if the specified pathname, together with the usual other criteria (-r, -D, sticky attributes, etc.), selects more than one *revision*, complain. The existing (I think) test cares about theoretical ambigity; my proposed one cares only about the practical problem -- the impossibility of stuffing two unrelated revisions into one sandbox file. If an operation isn't trying to do that, forbidding it on theoretical grounds seems pointlessly annoying. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS history and tag vs rtag
On Thu, Sep 11, 2003 at 05:30:22PM +0200, Martin FUZZEY wrote: The documentation clearly states that only a rtag operation (and not the normal tag) operation writes a history entry. These threads from the list archives are of particular interest: http://mail.gnu.org/archive/html/info-cvs/2001-08/msg01156.html http://mail.gnu.org/archive/html/info-cvs/2000-11/msg00404.html -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Diff treats files as text after they have been flagged -kb
On Fri, Sep 05, 2003 at 02:49:25PM -0400, Jack Dodds wrote: I used cvs admin to attach the -kb flag to all the .WPJ and .TGT files both in the repository and the sandbox, expecting this to fix the problem. Are you sure it affected the sandbox? See what cvs stat says about the files in question. I don't use WinCVS, but in vanilla CVS, cvs admin -kb *only* affects the repo. You then have to cvs update -A to get the new setting into your sandbox. Another possibility is that cvs diff might ignore the -kb setting, and just do whatever vanilla diff would do given the same files; which is, to do the diff as text-mode if the files look like text, and as binary-mode if they look like binary. I really don't know whether this is the case, however -- the code (1.11.5) looks as though it *should* use the file's -k setting, but a quick test indicated the opposite: I set a plain-text file to -kb; did cvs update -A, and verified it with cvs stat; modified the file; ran cvs diff, and saw a text-mode diff. I could of course export the whole project and import it into a completely new repository, If the first of my guesses is correct, that'd be drastic overkill; if the second is, it'd be completely pointless. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to programmatically restrict a /bin/rm command in a repository?
On Tue, Sep 02, 2003 at 05:24:53PM -0400, Christopher Rumpf wrote: I have some developers who simply refuse to use the 'cvs rm', 'cvs delete' and 'cvs remove' commands. Instead they log into the CVS server (using SSH), cd into the repository and /bin/rm the ,v files which they are concerned about. (yikes!) Configure SSH to prevent them from getting interactive sessions. Restrict these bozos to exactly one command: cvs server. The only way I can think (right now) is to write a script that will run for every single /bin/rm command which will first make sure that the repository path is not in the path to be deleted. This seems very inefficient. And hopelessly insecure. What's to prevent them from going behind your script's back to the real rm command -- or writing their own delete-file command? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: One repository with different names?
On Wed, Aug 20, 2003 at 08:51:05AM +0200, Matthias Teege wrote: Is it possible to made a working copy at home from (cvs.my.net) and later checkins to the same server under mycvs.dyndns.org? To do this as a one-off, just execute the command as cvs -d mycvs.dyndns.org:/wherever ... To automate that, you'll have to modify all the CVS/Root files in your sandbox to refer to the repo by its new name. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: get list of branches
On Fri, Aug 22, 2003 at 09:39:21AM +0100, Euan Guttridge wrote: Is it possible to retrieve a list of branches in a repository? Not easily. Post-processing the output of cvs stat -v is about the size of it. N.B.: There's a file $CVSROOT/CVSROOT/val-tags that is supposed to list all the tags (branch and revision tags both) in the repo, but it's not always accurate, so it's best not to depend on it. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to determine the previous revision number?
On Thu, Aug 07, 2003 at 06:42:43PM -0400, Dickson, Craig wrote: Or alternatively is there a known algorithm, that given a CVS revision number, can determine what the previous revision number was? if the last component (the Z in 1.3.2.Z) is greater than 1 decrement it else if there are more than two components strip off the last two components else // there are exactly two components, X.1 this was the first revision; it has no predecessor 1.5 - 1.4 - 1.3 - 1.2 - 1.1 1.3.6.2.2.2 - 1.3.6.2.2.1 - 1.3.6.2 - 1.3.6.1 - 1.3 - 1.2 - 1.1 Notes: - For CVS, the first component is very likely to be 1; however, it *can* have a different value (especially in ,v files originally created with raw RCS) - If rev. 1.1.1.1 exists, it's a special case, with two subcases: - 1.1.1.1 is usually identical to rev. 1.1; in this case, consider 1.1.1.1 to be the first revision, and ignore 1.1 entirely. This subcase arises when the ,v file was created by cvs import. That wants the first revision to be 1.1.1.1, but the RCS file format doesn't allow that (you can't have a branch with no root), so import creates rev. 1.1 simply as a root to which to anchor 1.1.1.1. - If 1.1.1.1 differs from 1.1, don't ignore either of them. It's not clear what you *should* do here, since (the file format's logic notwithstanding) it's possible that neither rev. is really an ancestor of the other; they've probably descended from a common ancestor that isn't available in CVS! (Kind of like humans and gorillas, whose common ancestor is long extinct.) This arises when the file was created locally via cvs add; cvs commit, and someone subsequently did a cvs import of that file. Note that you can distinguish these two cases from the log output, by looking at the +N -M indicators on 1.1.1.1, so you don't have to cvs diff them. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: should we branch or tag every time we add a file?
On Sun, Aug 10, 2003 at 11:58:09PM -0400, Larry Jones wrote: If you want to get a previous release, you either need to have a tag or you need to get it by date. In either case, CVS won't include files from the future. But if you want to change that previous release (to create a patch release due to an urgent bug fix, for example), and commit your changes, you need a branch. (If you *don't* want to create patch releases, the branch won't be used; but having it doesn't do any real harm; but it does clutter up the repo with empty branches that you have to keep track of, or at least remember to ignore in the cvs log output.) Thus, depending on your needs in the future, you might need either a tag, or a branch, or both. If you have a tag, though, it's easy to create a branch based on that tag, but it's difficult to go the other way. A good approach can be to create only a tag, for now. If you later need to patch the release, you can create a branch at that time to hold your changes. In the meantime, you've avoided cluttering up your repo with unnecessary branches. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strange behaviour with cvs rlog and branch tag
On Tue, Aug 12, 2003 at 11:36:42AM -0400, Larry Jones wrote: Olivier Imbrechts writes: When listing files tagged with a branch tag I only get directories while it works fine with simple tag. There aren't any revisions actually on the branch yet (the root is not on the branch), which is why you're not getting any results. I don't think that's a bug, but it might be possible to convince me otherwise. It seems to me that the root is on the branch, in the sense that cvs up -rBRANCH will yield it (i.e. it's on the branch in the CVS sense, even if not in the RCS sense). However, I can see wanting to ask either question: - For which files has someone actually committed something to the branch? - Which files have branch tag X, i.e. which files will be in my sandbox if I do cvs update -rX? So it's hard to argue that either of the two behaviours is correct or a bug; either one could be what the user's looking for. It's the same difference as that between cvs log -rX:Y and -rX::Y. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to determine the previous revision number?
On Thu, Aug 07, 2003 at 06:47:06PM -0700, Paul Sander wrote: This algorithm does not consider: [lots of things] Woops, you're right! The next time I have a sneaking suspicion I might be writing beyond my knowledge ... I'll listen to it :-/ -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: simple performance question on CVS
On Sun, Aug 03, 2003 at 08:23:38PM -0400, Larry Jones wrote: The trade-off is that you have to read the entire file in order to verify the checksum. Since SCCS has to read the entire file anyway, there's no additional overhead. RCS, on the other hand, doesn't have to read all of the diffs, particularly if you're just checking out the head revision which, in the RCS philosophy, is by far the most common operation. True, but an RCS-like format could checksum each individual section, instead of the file as a whole; e.g. one checksum covering the admin and all the delta's, and then a checksum for each individual deltatext. This still wouldn't catch errors in deltatext's you weren't reading at the moment, but when it did finally catch an error, it'd know right off what was wrong -- none of this random-file-format-error stuff. (No, I'm not suggesting this for RCS or CVS! Just hypothesizing.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: On commit, get log editor session for each sub-directory
On Fri, Jul 18, 2003 at 05:55:47AM -0700, Posts wrote: When I edit files in two or more sub-directories in a project and commit the changes, I get a log editor session for each directory. [...] I don't see this using another CVS system I work with. The editor-per-directory thing is indeed a feature. But it only works in local mode; when you use CVS client/server, you get a single editor session for the entire commit. There's no config setting to change this behaviour, but the above suggests a kludge that might work. Try checking out your sandbox with -d :fork:/my/repo/location (I may well have the syntax wrong), to force CVS into client/server mode even though the repo is on the local machine. Certainly -d mymachine.mydomain.com:/my/repo/location will do what you want, but I suspect it'll slow CVS down more than fork mode would do. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: file missing from 'cvs -nq up'
On Tue, Jul 08, 2003 at 01:03:52PM -0700, Steve Harris wrote: P1 : /home/p1/cbc/scripts % ls -l go.orig ... 20371 Jul 4 08:13 go.orig [...] P1 : /home/p1/cbc/scripts % cvs -nq up [expected to say ? go.orig, but doesn't] *.orig is in the default ignore list. Try: cvs -nq up -I! quoting the ! however your shell requires it. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Sandbox file date unexpected
On Wed, Jul 02, 2003 at 03:23:59PM -0500, Arachtingi, Mike wrote: I'm confused about the date that W2K shows for a file in my sandbox, after I commit it. I understand that CVS keeps track by UTC, but why doesn't my OS show the current time, local, that the file was last changed?- BTW, this doesn't happen if the file does not have any keywords. Right. To do the keyword substitution, CVS has to rewrite the file in your sandbox; hence, the written-to date changes accordingly. If there are no keywords in the file (or if keyword substitution is disabled), CVS doesn't bother rewriting the file, so the date doesn't change. So that part of what you're seeing makes perfect sense. For example, I edited and committed a file named LH.java, containing the keyword $Name:$. Note that before the commit, the local timestamp of the file was today, 1:42 PM Central US. After, the OS reports that the time is 12:05 AM tomorrow. Does this seem wrong? I don't know. I just tested it on Linux, and CVS (1.11.2.1, in case it matters) explicitly (using utime()) set the sandbox file's timestamp to the current *local* time of the commit operation. (The new revision in the repo is dated in UTC of course.) I'd naively expect the same under Windows, but I'm not familiar enough with that situation to know what else might be going on. What time was it when you did the commit? What time did your W2K client think it was? What time did the server think it was? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checkout files to the same working directory
On Mon, Jun 30, 2003 at 12:39:14PM -0400, Martyn Klassen wrote: I'd like to be able to checkout files from different locations in the repository to the same working directory. [...] I would have thought it would be relatively easy for the information about file location to be stored in the CVS/ directory inside the working directory. Is this possible? Not with CVS as it currently exists. If you look more closely at the CVS subdirectory, you'll see why: CVS/Repository says which directory in the repo the files came from, and it can't point to two directories at once. You can easily check out a *subdirectory* from a different place in the repo, but you can't mix files from two repo directories in one sandbox directory. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: difference between 1.1 and 1.1.1.1
On Mon, Jun 23, 2003 at 03:18:57PM -0500, Ronald Petty wrote: I was wondering what is the difference between 1.1 and 1.1.1.1? In the usual case, there isn't any. If you import a new file (one that isn't already known to CVS), the program imports it to rev. 1.1.1.1. Ideally that would be the whole story, but the underlying RCS file format doesn't let you create a branch without a root. So CVS checks in rev. 1.1 as well, and makes 1.1.1.1 identical to it. In unusual cases, the two can differ. For example, suppose you: - import Version 3 of some third-party package - locally create a new file foo, and commit it - import Version 4, which contains a file foo (doesn't matter to this discussion whether the two are related -- though of course it will matter to you during the merge!) At this point, Rev. 1.1 will contain your local version of foo, and 1.1.1.1 will contain the one from Version 4 of the package. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Using dos2unix on commit???
On Fri, Jun 13, 2003 at 06:01:18PM -0400, Larry Jones wrote: What do you mean by [line-ending problems] causing merges to panick? I can see causing the developer to panic since the entire file will be completely different from CVS's perspective, but CVS shouldn't have a problem with it. I suspect he was using panic in the mundane, informal sense of freak out, not the jargony sense of abort. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored...
On Wed, Jun 04, 2003 at 02:19:44PM -0700, Peschko, Edward wrote: [ Larry Jones wrote:] Damn straight. If you want software that thinks it knows more than you etc... But that goes contrary to the dictum there's more than one way to do it. Umm, you've got the wrong Larry :-) No way is that expression generally accepted computing wisdom. It's just a summary of the philosophy (to use the term rather loosely) behind Perl's design (or rather, lack thereof). -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Removing sticky tag 'HEAD' in cvs
On Wed, Jun 04, 2003 at 01:25:09PM +1000, Matthew Herrmann wrote: Given what HEAD means, it should never make sense to run: cvs up -rHEAD Occasionally one might want a sticky tag on HEAD -- probably not for an entire sandbox, but for a file or two. This came up a couple of months ago: http://mail.gnu.org/archive/html/info-cvs/2003-04/msg00023.html (The only reason I didn't suggest typing exactly -r HEAD is that I didn't think of it at the time...) Given that, can the up -r option refuse to take HEAD as a tag? HEAD is already a 'magic' tag so it's not as if this will cause CVS to lose generality. Given that, and also given principle of least surprise, -r HEAD should do what -r any-other-revision-tag does. If one of the cvs maintainers is listening, can this be put on the wish list? -1 -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Command-line multi-line messages for commit
On Tue, Jun 03, 2003 at 12:46:42PM +0300, Stephen Biggs wrote: I got it to work using another way which actually works better if you don't want to be so interactive (one press of the enter key instead of 3): $ cvs ci -m line 1'$\n'line 2'$\n'line 3 Yikes! Non-interactive it may be, but pretty painful! How about writing a wrapper shell script? You would invoke it as: cvs-wrapper -m 'message\ncontaining\nmultiple lines' other-args It would have to do something like: - extract (and remove) the -m and its value from the command line - turn the \ns into newlines (and any other transformations you like) - export CVSEDITOR=`which cat` into the environment - go: echo $transformed_log_message | cvs $other_args -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The idea isn't clear...
On Wed, May 28, 2003 at 07:29:58PM -0400, Greg A. Woods wrote:
[ On Wednesday, May 28, 2003 at 15:24:09 (-0700), Jim wrote: ]
stuff
===
other stuff
It's one hell of a lot easier to tell what's going on with conflicts if
you fix CVS to call diff3 in such a way that it includes the full
conflict information:
[reluctantly quoting almost the entire patch, since I don't see
how to edit it down...]
$ cvs diff rcscmds.c
[...]
***
*** 245,254
--- 245,258
char *tmp1, *tmp2;
char *diffout = NULL;
int retval;
+ struct stat file_info;
if (options != NULL options[0] != '\0')
assert (options[0] == '-' options[1] == 'k');
+ if (CVS_STAT (workfile, file_info) 0)
+ error (1, errno, could not stat %s, workfile);
+
cvs_output (RCS file: , 0);
cvs_output (rcs-path, 0);
cvs_output (\n, 1);
I suspect that the above diff hunk is an unrelated change. It
seems unrelated to the conflict-marking style.
***
*** 298,305
only for diagnostic messages -- CVS no longer forks to run diff3. */
diffout = cvs_temp_name();
call_diff_setup (diff3);
! call_diff_arg (-E);
! call_diff_arg (-am);
call_diff_arg (-L);
call_diff_arg (workfile);
--- 302,308
only for diagnostic messages -- CVS no longer forks to run diff3. */
diffout = cvs_temp_name();
call_diff_setup (diff3);
! call_diff_arg (-ATam);
call_diff_arg (-L);
call_diff_arg (workfile);
I used to make this change too (well, the s/-E/-A/ part; the -T
is orthogonal), but recently discovered a drawback -- for me,
it's a showstopper; I've had to revert the change.
Suppose you make a local change to a third-party package (I use
the vendor branch, but I strongly doubt that's relevent). You
submit your change, and it's incorporated without modification
into the canonical source. When you merge after importing the
new version, CVS decides that what looked at first like a
conflict, really isn't, because the conflicting change is
identical in both child versions. CVS just accepts the change,
and prints this message:
${file} already contains the differences between ${rev1} and ${rev2}
The problem is that the s/-E/-A/ patch breaks this detection, and
instead of a nice message, you get spurious merge conflicts.
I think the problem is in diff3. -A does two things:
1. makes diff3 dumber about identifying conflicts (suppresses
the intelligence that would have suppressed the conflict in
the above case)
2. once a conflict has been identified, displays its ancestor
version as well as the two child versions
Of course, (2) is what we're after, but diff3 provides no way to
get that without also getting (1).
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: System password authentication
On Fri, Apr 11, 2003 at 05:47:15PM -0400, Larry Jones wrote: Brian Murphy writes: But this code rejects a blank password given by the user, should that not be accepted according to your explanation. [...] you're also correct that it accepts a non-blank entered password as matching a blank system password but rejects a blank entered password. I have no idea why -- the code seems to have been that way forever. The log message for the original version of that code, way back in 1.43, was: * server.c (check_password): If user has a null password, then just return 0. Reverse sense of return value. Caller changed. My guess would be that in doing the two things at once, he got confused and coded his new test to the old interface, in which 0 meant *success*. (check_password just returned a boolean value in those days, not a pointer.) The comments were written years later, by someone else, and appear not to make much sense either. Of course their author must have assumed the code was doing something reasonable :-) The fascist side of my personality wants to reject any attempt to use a system account with no password, the more liberal side says that if someone is stupid enough to have an account with no password then they deserve whatever happens :-) (one can argue whether than means accepting any password at all or just a blank one). If the password field in /etc/passwd (or /etc/wherever-else) is empty, UNIX login traditionally doesn't even prompt the user for a password. Linux Mandrake 7.2 and FreeBSD 4.8 are still like that, but Solaris 7's login treats the password as expired and prompts me for a new one. If, on the other hand, the field contains the encrypted version of , the user *is* prompted, but only a null line is acceptable as a response. That's still true in Solaris. I don't know about the others -- it's harder to test on them, since their passwd(1) commands refuse to let me set an encrypted-null-string password. Ideally, CVS would emulate login's behaviour, by not prompting for a password if the field is null. But the little I know of CVS's internals suggests that trick is impossible -- by the time the username hits the server, I imagine the password's already been prompted for. Given that, it seems to me that least surprise should trump emulating login's intent -- CVS should accept only a blank password, *not* any at all. Opinions from the peanut gallery? Yeah. Anyone actually doing this is going to find their repository -- if not their network -- resembling peanut *butter* :-) The no-password == no-prompt trick would have been useful in CVSROOT/passwd, though, for read-only anon-CVS access -- no less secure than publishing the password on a web site as everyone does now, but certainly less annoying. Oh well. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / My Wine works. However it crashes about half the time on startup. Apparently their simulation of windoze API is getting too accurate. :) - Kyle Sallee ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Query regarding Branches in CVS
On Fri, Apr 04, 2003 at 08:50:49PM +0530, Amit Sood wrote: Now if I have one file ABC.txt present in both branches,can I lock this file seperately for both the branches.This means if I have locked for main branch it is still unlocked for RELBRANCH1 and other way around. I don't know. CVS doesn't really do very well at locking files or revisions so that only one person can make changes. By the way, a better term for this idea is exclusive checkouts, to distinguish this form of locking from other forms (one of which I'll be talking about later). The main goal of CVS was to avoid needing exclusive checkouts, so that two (or more) people could work on the same file at the same time. That works well for text files, but for binary ones like JPEGs, MS-Word docs, etc., one really wants exclusive checkouts. But CVS's support for that is slim to none. There are features like watches and cvs edit that people find useful, but I don't really know much about them. Also if two users make changes to ABC.txt one user make changes to ABC.txt in main branch and other in RELBRANCH1 and these changes at exactly same moment of time will CVS will be able to handle such a scenario successfully. Yes. There are two issues, but CVS handles them both: - Keeping the two changes straight. That's just what branches are for. Someone who checks out the main branch, and someone else who checks out RELBRANCH1, will each get the right version. - Concurrent-update locking, to avoid corrupting the repository. CVS does this; if both users commit their changes at the same moment, one of them will have to wait a short time for the other one's commit to finish. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: directory not relative within the depository
On Wed, Apr 02, 2003 at 07:47:22AM -0700, jda wrote: This structure will be preserved when importing? Yes. To edit your example slightly, you're starting with a newly-inited repo in /usr/local/cvs-repository, and project source on a CD: /mnt/cdrom/Foo/ package1Dir/ foo1.java foo2.java package2Dir/ foo3.java foo4.java The (variant) commands I gave yesterday: cd /mnt/cdrom/Foo cvs import -m Imported sources MyProject/something/Foo MyCompany start will give you this in the repo: /usr/local/cvs-repository/ CVSROOT/ ... MyProject/ something/ Foo/ package1Dir/ foo1.java,v foo2.java,v package2Dir/ foo3.java,v foo4.java,v -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
On Wed, Apr 02, 2003 at 12:28:48AM -0600, Wade Williams wrote: But is there a way I can tell CVS - always update this file on an update, but ignore my changes on a commit? No, but you can get part-way there, by explicitly updating to the HEAD revision of the file. Find out what the HEAD revision is (for the sake of argument, say it's 1.4), and type: cvs update -r1.4 myfile Then, attempts to commit the file will die with this message: cvs commit: sticky tag `1.4' for file `myfile' is not a branch cvs [commit aborted]: correct above errors first! It doesn't do what you want automatically, but at least it gives you a noisy reminder to do it manually, and prevents CVS from doing the wrong thing if you forget. Unfortunately, updates will not update/merge the file; they'll update everything else and silently leave that one alone. You'll have to remember to periodically update it yourself: # Merge changes cvs update -A myfile # Don't change the file, but pin it at the new HEAD rev. cvs update -rnew-head-rev myfile That's the cost of using a sticky revision tag for its usually-annoying side effect, rather than for its intended purpose :-) CVS should probably print a warning in this case, but it doesn't. So this trick only gives you one of your two requirements, but arguably the more important one. The mistake it prevents you from making is the one that would affect other peoples' work, while the mistake it still permits will affect only your own. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
On Wed, Apr 02, 2003 at 02:01:30PM -0500, Larry Jones wrote: Eric Siegerman writes: CVS should probably print a warning in this case, but it doesn't. This case is updating a file with a sticky tag or date, which seems like a good idea to me, too. Anyone disagree? Sticky *revision* tag or date (which is what I'm sure you meant :-). Issue: should CVS always complain, or only when it would actually have done something? The two options are: a. print a warning if a sticky revision tag or date is encountered during cvs update b. Like (a), but only if the revision named by that tag/date is different from the one CVS would otherwise have updated to Personally, I'd much prefer (b). If the sticky tag/date names the revision I'd have gotten anyway, then the end state I was requesting has been achieved; my sandbox is indeed up to date. It's only if the tag/date has prevented me from synchronizing completely that I need to make a decision. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
On Wed, Apr 02, 2003 at 01:09:44PM -0500, Todd Denniston wrote: if on the third hand (hey, where'd that come from?) each engineer needs their own config that does not change often and it for some reason can not be tweaked to the specific setup by a build script probably_bad_suggestionyou could each branch your version of the config file and not worry about the fact that it is under version control/probably_bad_suggestion. In this case, I typically make several files, and CVS-track those: httpd.conf-ERIC httpd.conf-SHIRLEY Or, back when CVS had options.h.in: options.h.in-FREEBSD options.h.in-LINUX options.h.in-SOLARIS What happens next depends on circumstances: - In both of the above examples, each sandbox then symlinks the appropriate variant into the working location. If it's a third-party package, I still CVS-track the un-suffixed real file -- httpd.conf or whatever -- but only for vendor updates and for local changes that should apply to all sandboxes. The trick I just posted about would be useful here -- setting a sticky revision tag on the real file to prevent accidental commits. I'll have to try that myself the next time the issue comes up :-) - Sometimes, the per-user files aren't hand-edited copies of the real file, but instead contain parameters to be substituted into a generic template. In that case, no symlink is made, but people (or the build system) have to rerun the template-substituter when the template or a user's per-sandbox parameters file has changed. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: directory not relative within the depository
On Tue, Apr 01, 2003 at 02:26:20PM -0700, jdaues wrote: Newbie error: Trying to create a project from source code Source code is on cdrom in /mnt/cdrom/Foo/ CVSROOT is set to /usr/local/cvs-repository Created repository with: cvs -d /usr/local/cvs-repository init Ok so far. Create /usr/local/cvs-repository/Foo Command is (after 3.1.1. in cederqvist): cvs import -m Imported sources /mnt/cdrom/Foo MyCompany start The first argument isn't where to find the input files, but where within the repository to put the results. It must be a relative pathname, and is interpreted relative to CVSROOT. The source for cvs import is always the current directory. So what you wanted was something like: cd /mnt/cdrom/Foo cvs import -m Imported sources Foo MyCompany start That argument can have more than one level. You could say: cvs import -m Imported sources MyProject/something/Foo MyCompany start if you wanted the stuff to end up deeper inside the repo. (CVS will create the intermediate directories if necessary.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Moving branch to trunk
On Tue, Apr 01, 2003 at 05:39:15PM -0800, Ed Swierk wrote: Now I would like to merge everything from the branch into the trunk, ignoring any changes made in the trunk since the branch was created and removing any files in the trunk that are not present in the branch. http://mail.gnu.org/archive/html/info-cvs/2002-09/msg00226.html -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Branching behavior and binary file Qs
On Sat, Mar 29, 2003 at 01:51:15PM -0600, Steve Lane wrote: The moment I import Prod-Old, all its files are already at 1.1.1.1. Yes. See: http://www.cvshome.org/docs/manual/cvs_13.html#SEC104 in particular the introductory 13. section preceding Section 13.1. Each of them has a previous version 1.1, which in every case I've looked at is identical to 1.1.1.1. An artifact of the underlying RCS file format -- you can't have an RCS branch that that doesn't branch *from* anywhere. So CVS has to create rev. 1.1, simply as a root for the vendor branch. Question 2: the production version of the app contains many large binary files. I have no desire to CVS these. I know how to use cvsignore to skip them, but don't they then get deleted if I do a full checkout and replace the production version of the app? Yes. If instead you do cvs update in the existing production directory, the binaries will be left alone. The alternative is to restore the binaries after a checkout, by some means external to CVS. How you do this rather depends on what the binaries consist of: human-edited images would need to be copied or symlinked in from somewhere else, but for compiled code you might decide to just recompile it. In either case, the usual approach is to write a script, Makefile, or whatever to drive the process -- and then track that file in CVS. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Manual, section 2.9.2
On Tue, Mar 25, 2003 at 04:50:41PM -0700, John Daues wrote: In the CVS manual, in section 2.9.2 Connecting with rsh, it says: --- For example, suppose you are the user `mozart' on the local machine `toe.example.com', and the server machine is `faun.example.org'. On faun, put the following line into the file `.rhosts' in `bach''s home directory: toe.example.com mozart Then test that `rsh' is working with rsh -l bach faun.example.org 'echo $PATH' --- Should the 2 occurences of bach be replaced with mozart? (or vice-versa). If not, who is bach? Arnold. (there's a setup for a joke) Ok, so I had to bite. Seriously, the names should *not* be replaced. bach is the repo's owner, on faun. You can connect via rsh to a repo on a machine where your username is spelled differently, and the example is constructed to demonstrate that. A better choice of names might have been bach and jsb, to suggest that they're the same person. It's also possible to use this capability in the way the example implies -- to let entirely different people all access the repo using the same login on the server. Whether you *should* set things up that way is a matter for serious -- indeed, extended, recurring, and flame-prone -- debate. I don't blame you for being confused. The example never says who bach is; you have to infer it. I'll be sending a patch for that to bug-cvs in a minute. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Log data for branches
On Tue, Mar 25, 2003 at 03:20:50PM -0800, Mike Ayers wrote: [cvs log -rbranch1, on a file without the branch, says:] cvs server: warning: no revision `branch1' in `/export/cvs/personal/mayers/testing123/z1/SwingApplication2.java,v' RCS file: /export/cvs/personal/mayers/testing123/z1/SwingApplication2.java,v [...] description: revision 1.2 date: 2003/03/25 22:48:26; author: mayers; state: Exp; lines: +4 -3 Better label. revision 1.1 date: 2003/03/25 22:30:56; author: mayers; state: Exp; countdown version: initial checkin = In 1.11.5, on that file, cvs log -rbranch1 would have suppressed the revisions, though it would still have printed the header information. The new(ish?) -S option would have suppressed the header as well, leaving only the warning. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Log data for branches
On Tue, Mar 25, 2003 at 05:34:08PM -0800, Mike Ayers wrote: Hmmm - not the results I got... cvs server: invalid option -- S Usage: cvs server [-lRhtNb] [-r[revisions]] [-d dates] [-s states] Note who's complaining -- cvs server, not cvs log. Your client may be 1.11.5, but your server must be older. Try cvs version instead of cvs -v; the former prints out the server's CVS version too. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs inserting double ^M
On Thu, Mar 20, 2003 at 03:17:14PM -0600, Mark Offutt wrote: When others do a cvs update to get cvs commits from Joe, the files in question show up with inserted double control Ms (^M^M) at the end of each line. The culprit appears to be the particular version of cvs that Joe uses. The only difference that we find between his version and the rest of the team is that his is the server version (we all use GNU CVS for Win2K 1.11). I suspect that the client vs. client/server is a red herring. If I understand the distinction, it should have no bearing on newline conversion. Perhaps Joe has a .cvsrc (or the Windows equivalent) that forces all commits to -kb. That would be one explanation for this behaviour. BTW, 1.11 is ancient -- many bugs have been fixed since then. All of you (not just Joe) should consider upgrading to 1.11.5. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Emptydir change from version 1.11
On Mon, Mar 17, 2003 at 11:10:17AM -0500, Larry Jones wrote: The problem is that the mapping for ModuleB is not so obvious. What the current scheme does is: DirA$CVSROOT/Emptydir DirA/DirB $CVSROOT/Emptydir DirA/DirB/DirC $CVSROOT/. DirA/DirB/DirC/DirD $CVSROOT/Repox DirA/DirB/DirC/DirD/DirE$CVSROOT/Repox/RepoY DirA/DirB/DirC $CVSROOT/Emptydir seems to me a better choice. There may not be a truly right thing to do here, but $CVSROOT/. seems less right than the alternative, in the sense of less likely to be what the user intended or expected, and less likely to be what they'll find useful. (No argument about the other four, btw.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Updating from parent directory
On Mon, Mar 03, 2003 at 02:45:25PM -0500, Larry Jones wrote: Craig Dickson writes: Of course there is no real need to pass the -r MAIN argument, since it will default to this, but this means I need to have logic in my script to act differently depending on if it is the MAIN branch or another branch. Am I doing something wrong, or is it normal not to be able to refer to the MAIN branch just like any other branch? Like the error message says, there is no MAIN branch. There is a *default* branch, which is usually referred to as the trunk, but it is a virtual entity and has no name. If necessary, you can refer to the trunk with -A. In theory, that's not always safe, since it can reset other sticky attributes besides the branch. That said, it's never been a problem for me in practice. Either way, though, it's still a special case in your script. However, it's updates you're talking about. Once you've got all the subdirectories checked out -- using the -r foo or nothing, as appropriate -- the updates shouldn't have to specify a branch. A simple: cvs update -dP directory for each directory should work in all cases. Indeed, if you just say: cvs update -dP B1_0 B2_0 MAIN it should do the right thing -- but I'd want to test that before depending on it. (Note: the arguments there are the directory names, not the branch names.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: FW: Commit inconsistency: Up-to-date check did not fail thoughit should have !
On Mon, Feb 24, 2003 at 03:36:58PM +0200, Reinstein, Shlomo wrote: I have also looked up the sources of CVS. In commit.c, there's the following comment: (I'm quoting) /* Sending only the names of the files which were modified, added, or removed means that the server will only do an up-to-date check on those files. This is different from local CVS and previous versions of client/server CVS, Yikes; I had no idea! That does seem pretty conclusive, though :-/ but it probably is a Good Thing, or at least Not Such A Bad Thing. */ I'd sure like to know *why* he felt that. The commit message (src/commit.c rev 1.40) is no more revealing than the comment. I imagine the change was made as a speed improvement, but that doesn't seem sufficient grounds for the resulting violation of user expectations -- at least, not without more justification than was given. I just wonder how come this does not cause problems in the development of large projects that are kept in CVS. So do I! -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs via http
On Tue, Feb 18, 2003 at 04:44:06PM +, Christopher Mihaly wrote: Is there a way to access a remote cvs repository via http? httptunnel (http://www.nocrew.org/software/httptunnel.html) might be what you're looking for. (I've never used it, so can't offer any more than the URL.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Commit inconsistency: Up-to-date check did not fail though itsho uld have !
On Tue, Feb 18, 2003 at 06:35:35PM +0200, Reinstein, Shlomo wrote: This would be fine if CVS had consistent behavior when using a local repository and when using client/server. Until a short time ago, we used to work with a local repository (on a network drive), and we got used to that behavior. Our set of scripts around CVS rely on this behavior. It's supposed to work as you expect, locally and client/server both. I'm very surprised by the behaviour you saw -- so surprised that I can't help suspecting that something else was going on, since I don't believe I've ever seen an up-to-date check pass when it shouldn't. Technical details: - User A works on Linux, using CVS client server version 1.10.8. - User B works on Windows 2000, using CVS client 1.10.7 and server 1.10.8 (both users using the same CVS server machine, same version of CVS on both machines) Umm, those are pretty old! May I suggest upgrading to 1.11.5? No guarantee that it'll help, but it couldn't hurt. - The repository is on NFS. You probably know which red flag that's raising for me :-) But from what you say above, it sounds as though only the one CVS-server Linux box is accessing the repo directly (i.e. it's the only NFS client to touch it). If that's correct, it makes things less worrisome -- but I suppose there still might be interoperability problems between the Linux NFS client and your NFS server if it's on a different platform. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Commit inconsistency: Up-to-date check did not fail though itsho uld have !
On Tue, Feb 18, 2003 at 08:37:12PM +0200, Reinstein, Shlomo wrote: I also checked that this strange behavior was not fixed in CVS 1.11.1p1. I don't know about the newer versions (e.g., 1.15.1), I will check this as well. Darn! I was really hoping that was it. Well, maybe it's fixed in 1.11.5, but this new data point makes me less hopeful of that. What's wrong with the repository being on NFS? Larry summed that up admirably. Since you have a small reproducible test, could you try it with the repo *not* NFS-mounted, but local to the CVS server? Even if it still fails (as I half-suspect it will), at least we can stop harping on the NFS thing and look elsewhere :-) So whichever the outcome, it won't have been wasted effort. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport Or has an NFS implementation that won't interoperate with mine. - me ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Beginner needs help with modules
On Wed, Feb 05, 2003 at 12:46:40PM -, [EMAIL PROTECTED] wrote: But, if i have a line like test /XXX/YYY in my modules file and i make CVS checkout test i receive a message in terms of Cannot find module test: operation aborted. Just a guess: try removing the first /, to make it: testXXX/YYY -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: fetching multiple tags
On Wed, Feb 05, 2003 at 10:14:51AM -0500, CHARLES HART, BLOOMBERG/ 499 PARK wrote: The second checkout replaces any file that has a B tag (and leaves behind any file that should be deleted as-of B I think). No; the second checkout will not leave such files behind; it'll delete them. It will do its best to leave you with *only* the files (and the revisions of those files) tagged with B. The only exceptions I can think of are: - uncommitted changes; CVS will merge them rather than clobbering them - files not in CVS at all (? status); those will be left alone A scripted approach, which would be more efficient is to collect the list of files and revisions first, and then get only the good ones. I believe that's the only approach that will work. Though I don't have an example database handy with deleted files, so I can't say what to do about discarding them from the list. Hmmm. In theory, this should probably just work -- deletion is just another revision, with a commit date. But I bet that in practice there'll be ugliness involved :-( But as Larry said to the original poster: No. You're expected to tag all the files in a module, not just some of them. Indeed. In CVS, tags are meant to label the state of the module at a given point in time, not the transitions. For the latter (and given that you've tagged the states in the first place), use cvs diff -rtag1 -rtag2. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: noncvs under cvsroot
On Wed, Feb 05, 2003 at 02:08:34PM -0500, Mohamed Metwaly wrote: Iwant to put non-cvs directories and files under cvsroot [by which I think he means files and directories that aren't CVS-tracked.] Re. non-CVS files: strictly speaking, I think you can get away with it. But it's a very strange way to do things; it's absolutely *not* how CVS is intended to be used. And don't forget that the non-CVS files won't be visible client/server (unless you remote-mount the repo, which should be avoided, since that can be dangerous). Re. non-CVS directories: CVS doesn't revision-control directories in the first place, so I don't suppose there would be much distinction within the repo -- whether a directory is considered CVS or non-CVS would simply depend on which sort(s) of files it contained. If you explain what you're trying to accomplish, maybe we can suggest an approach that's more in line with the way CVS wants to do things. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: NEWBIE: Multiple source directories in a single project?
On Wed, Feb 05, 2003 at 04:54:15PM -0500, KEVIN ZEMBOWER wrote: How would I use CVS to organized a project called prds which had source code in /usr/local/src/prds and documentation in /usr/share/docs/prds and library files in /var/lib/prds? If I can understand this, I can probably translate it to my problem. You'd organize it as: project-root/ src/ doc/ lib/ Then write a top-level Makefile (or similar) containing an install target to copy everything to where it needs to be in production. In other words, pretty much the way the CVS distribution itself is organized. N.B.: project-root isn't any particular directory. By default it will have the same name as the CVS module (probably prds in your case), but each developer is free to override that by giving their working directory any name they like, and to put it anywhere they like. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Can't do setuid
On Tue, Feb 04, 2003 at 04:35:47PM -0500, Brian Kowald wrote: For my whole repository, I set the file and directory owner to cvs and the group to cvsusers. I did this recursively. Setting the group is good. Setting the owner doesn't help much; as you've discovered, it doesn't stay set for very long... I set set group id bit for the entire repository with'chmod -R g+s'. This is so that new files will have the correct group and owner. That should only have been done on the directories, NOT on the files. However, everything should be g+w. So from a standing start, it'd be something like: chmod -R g+w find . -type d -print0 | xargs -0 chmod g+s (That's with GNU findutils. Without it, the g+s pipeline is harder to do both safely and quickly. This has been discussed here in the past; see the archives for details). Of course, from your current state, your task is to turn *off* setgid on the files, not to turn it *on* on the directories... A couple more steps are needed: - Add the users to group cvsgroup (then have them log in again to pick up the change) - Make sure that users' umasks do NOT include the 020 bit, i.e. that they create files group-writable. Of course, this has possibly-unpleasant ramifications for non-CVS files; the CVSUMASK environment variable *might* be of help, depending on your setup. When I go and look at the repository, the owner has changed to the user doing the cvs command. That's as expected. Once the group stuff that we're talking about is set up properly, this behaviour shouldn't cause any problems. (Indeed, working around this is a lot of the point of the group stuff in the first place.) When I execute a cvs update, I get the error message Can't do setuid' I have a few thoughts, but nothing concrete: - Do you have setuid or setgid enabled on the CVS executable itself? If so, turn them off. - One of the other suggestions might fix it (especially turning off setgid on the ,v files). - That message doesn't seem to occur in CVS 1.11.5. Which version are you using? If it's an old one, try upgrading. - Or are you using another implementation, e.g. WinCVS, cvsnt, etc.? If so, you might have better luck on the appropriate list. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Can't do setuid
On Tue, Feb 04, 2003 at 06:29:04PM -0500, Greg A. Woods wrote: [ On Tuesday, February 4, 2003 at 17:48:24 (-0500), Eric Siegerman wrote: ] chmod -R g+w find . -type d -print0 | xargs -0 chmod g+s You don't want the ,v files to be writable by anyone. So, just this: find . -type d -print0 | xargs -0 chmod g+sw Doh! I'm obviously more sleepy than I thought. Thanks, Greg. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Removing a branch
On Fri, Jan 31, 2003 at 04:43:34PM +0100, Ludvig Borgne wrote: A simple question - is it possible to remove a branch? I have tried: cvs rtag -b -d branch_name module_name The -b should be -B. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Discarding changes from one revision and committing changes...
On Thu, Jan 30, 2003 at 10:41:27AM -0500, Larry Jones wrote: ADFH writes: If X is at version 1.21, and I want to go to version 1.20, make some changes, and then commit the file back as 1.22, how do I go about it? cvs up -A file # get the current revision of the file cvs up -j1.21 -j1.20 file # back out the unwanted changes To which I would add: cvs ci file # commit the back-out, *before* making the new changes vi file # make whatever other changes you want cvs ci file # check it in -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Restoring repository on basis of backup
On Mon, Jan 27, 2003 at 12:33:08PM +0100, Jarl Friis wrote: I had a disk-crash. But I happend to save the home partition. I have a rather old backup of the CVS repository that I have now reestablished plus a more recent versions of some directories checked out of the CVS prior to the crash. I now want to update (commit) my working revisions of the files for those directories that I have checked out prior to the disk-crash. See this thread: http://www.mail-archive.com/info-cvs@gnu.org/msg21518.html -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Panic error code -39?
On Wed, Jan 22, 2003 at 08:42:34AM -0600, Beachey, Kendric wrote: From: Riechers, Matthew W [mailto:[EMAIL PROTECTED]] Prem Prakash Pathak wrote: cvs [checkout aborted]: Internal error: cvs_hqx.cpp, 635: Panic Error (-39) The Mac has a zillion error codes. According to http://www.usc.edu/isd/doc/os/mac/consult/oserrors.html, this one's definition is: -39 eofErr End of file; no additional data in the format Which just confirms what someone else posted. [At MWR's shop] They occasionally get some weird error with a negative number, although I think theirs are usually in the fifties. Same result, though: we don't have any idea what is really wrong. Some file system error, it looks like (those range from -33 through -61). Looking yours up on that oserrors page the next time it happens *might* help you pin down what's happening in your case. The solution I give them always works: delete the offending section of your working copy (which sometimes means the whole thing) and do an update to pull a fresh copy. Hard to argue if it works. Still, it'd make me nervous trusting that the problem will only occur on updates, and never on commits... -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT write permission vulnerability
On Wed, Jan 22, 2003 at 03:55:15PM +0100, Fabian Cenedese wrote: I'm starting to wonder if removing :local: mode might not be a bad thing. That's a bit extreme, IMO. At most it could be disabled by default, with an option to enable it (either a configure option, or in CVSROOT/config, or both). Not a flat-out prohibition, but people would have to work a bit to find it. The only thing you could possibly imagine is to disable local mode on network mapped drives. That'd be nice. Rather a challenge to implement though -- how *does* one tell, portably and from application code, whether a given directory is locally or remotely mounted? But while working on my local drive I don't want to mess with any server stuff. Indeed! I might not even have any server stuff set up yet by the time I want to start using CVS. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT write permission vulnerability
On Mon, Jan 20, 2003 at 10:53:38AM -0500, Larry Jones wrote: As CVSROOT requires write permission, it has 777 permission for all. Setting the sticky bit (chmod -t) on a directory prevents normal users from deleting or renaming files in that directory unless they own them. Doing that in the repo would break CVS completely, wouldn't it? For most users, a commit would fail at the point where it tried to delete the old ,v file and rename the temporary copy (indeed, the sticky bit would independently block both of those operations). So only the owner of a given ,v file, and the owner of its parent directory, would be able to commit new revisions. To the original poster: Larry's main point still holds. Use client/server, not NFS. That'll also help you with the permissions problem, if you do it right. Doing it right has been discussed here many times; for details, try searching the list archives. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Promotion groups
--- [EMAIL PROTECTED] wrote: However there is much momentum (culture and automated build scripts) that take advantage of PVCS promotion groups which are like constrained, floating tags. (They are constrained in the choices the developer can chose from, such as Dev, Test, Staging, Prod). Is there any way to simulate this in CVS? The floating part's easy; see the -F option to cvs tag. I don't know about the constrained part. CVS doesn't do that out of the box, but perhaps it can be enforced using one of the CVSROOT/*info files. On Thu, Jan 16, 2003 at 06:38:57AM -0800, Kyle Adams wrote: We're also debating about ways to keep track of previous versions tagged for each environment. We'd like to do this to provide rollback functionality [...] You could set two tags, a floating one for the scripts and a non-floating one for the humans, e.g. Test and Test-20020115 respectively; or else set only the non-floating tag, and use some mechanism external to CVS to tell the scripts which tag corresponds to the current test build. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tagging Problem
On Wed, Jan 15, 2003 at 11:04:20AM -0500, Larry Jones wrote: Amit Sharma writes: I have a strange tagging problem I have started tagging at the same time to same Repository from 2 different machines with different tag names [...] What version(s) of CVS are you running? Could an NFS-mounted repo with screwed-up locking lead to these symptoms (valid ,v files but with tags applied inconsistently), or would the individual ,v files end up broken instead? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How is a patch applied to CVS?
On Thu, Jan 09, 2003 at 11:14:59AM +1100, Matthew Herrmann wrote: But can patch be run in such a way that it generates conflict markers instead of .rej files? I don't think so. Or is diff3 the go here instead? Yup. There's also merge. That's part of the RCS distribution; it's an intermediate layer between rcsmerge (which understands RCS files, revisions, etc., and which is thus pretty irrelevent in a CVS context) and diff3 (which does the real work). I don't recall offhand what value merge adds to diff3 -- a quick glance at its man page doesn't show me anything that diff3 isn't already doing -- but there must be something I missed, and whatever it is, it might be useful :-) Of course, diff3 is what CVS uses internally. It might be possible to structure your development process such that there's a CVS branch that the patch will apply cleanly to, so you can then use a CVS merge rather than messing with diff3 yourself. That's the theory anyway. I looked into this a few months ago, and found that I didn't have the time to script a solution that would work in our specific situation. In an open-source situation, with people submitting patches against various releases, nightly snapshots, and/or random cvs updates, I doubt this sort of approach has a chance. You'd end up with *zillions* of little one-revision branches, one for each submitted patch. Ick! -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Read Only User Tagging Files?
On Wed, Jan 08, 2003 at 09:05:00AM -0600, [EMAIL PROTECTED] wrote: I have a user with read only access to CVS. I want him to have the ability to write(commit) to one specific file and to tag all files in the repository while retaining his read only access to everything else. Is this possible? No: - You can't give tag permission without commit. You can only allow or disallow *all* writes, not selectively. - You can give a user write (= commit + tag + delete + ...) access to only one directory, but not to one file within a directory. Because of the way CVS works, it's the directory's permissions that matter, not those of the individual files. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How is a patch applied to CVS?
On Mon, Jan 06, 2003 at 08:23:52PM -0500, Mazza, Glen R., ,CPMS wrote: How is a patch file committed into CVS to update the most recent version? In several steps: - Apply the patch to a checked-out working directory - Resolve any conflicts (i.e. .rej files) - Compile and test - cvs commit CVS itself can't digest arbitrary patch files. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Removing directory in cvsroot
On Fri, Jan 03, 2003 at 10:12:05AM -0600, Daniel Hurtubise wrote: For example, my cvsroot directory has subdirectories PROJECT/1.0/, and now that I've figured out how to use tags for releases, I want to eliminate the 1.0 subdirectory in my directory structure. Can this be done? I take it you don't want to delete the contents, but just to move everything up a level, from PROJECT/1.0 into PROJECT. Is that right? If so... Yes, it can be done, but not prettily. You'd have to just go into the repo and move the stuff, then rmdir the now-empty 1.0 subdirectory. This would break everyones' sandboxes of course; they'd have to check out fresh, or else go through all their CVS/Repository files deleting the /1.0 substrings -- there are scripts for this sort of thing floating around, perhaps even in CVS's contrib directory. The reorganization might break old builds too, though, should you ever need to build a pre-reorg version. Or it might not, depending on the details of your setup. If this will be a problem, though, an alternative to what I've suggested would be something along this line: - copy, not move, the repo files from PROJECT/1.0 to NEWPROJECT - have everybody check out from NEWPROJECT (or retarget their sandboxes, as mentioned above) - keep PROJECT/1.0 around for posterity, but stop using it for any new work - chmod -R a-w PROJECT/1.0, to guard against accidental commits to the wrong place (actually you only need to chmod the directories, since the files should already be read-only) (Unfortunately, this approach requires changing the module's name; for a copy as opposed to a move, you can't just copy PROJECT/1.0 to PROJECT. If you did, CVS would want to check out both copies, giving you both PROJECT/foo and PROJECT/1.0/foo on a fresh checkout, or on a cvs update -d.) Another possibility would be to paper over the problem. Just add a line to CVSROOT/modules: NEWPROJECT PROJECT/1.0 Then people can say cvs co NEWPROJECT and get what they expect. This doesn't get rid of the 1.0 level. It doesn't even retire it from active use, since the NEWPROJECT name is *only* used for initial checkouts; after that, things work just as before, right down to the PROJECT/1.0/foo,v pathnames reported by CVS commands. So this is pretty ugly, but it's easy. It might make a good short-term solution until you're ready to implement one of the others -- especially if the copying approach is your long-term solution of choice, but there's still post-release bug-fix work happening on the 1.0 code, which would prevent you from retiring that (pseudo-) branch yet. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: update not getting empty directories
To begin, your statement of the problem is inconsistent. First you say (case 1): [...] sometimes checkouts and updates ignore directories that only contain other directories, even if those sub-directories contain source files. so if $CVSROOT/foo only has a directory called bar in it $CVSROOT/foo/bar $CVSROOT/ foo/ bar/ blat.c,v# Implied by your first sentence But then you say (case 2): Is there any way to make all clients always check out everything even if the directories are empty?? $CVSROOT/ foo/# Not even a bar subdir These are very different situations. There's actually a third case, intermediate between those two (call it 1.5): A directory contains subdirectories, but there are no files anywhere under it, at any depth: $CVSROOT/ foo/ bar/ subsub/ baz/ On Mon, Dec 23, 2002 at 10:46:29PM +, Steve Salazar wrote: I have a problem where a repository on a lan shared disk (both via nfs and samba) Potential problem 1: the shared repo. Don't do that; use client/server CVS instead. Actually, I can't see an obvious reason for the remote-mounted repo to cause *this* problem, but it's well known for causing *other* problems -- and rather more severe ones at that, such as corrupted ,v files -- especially in heterogeneous environments like yours! sometimes checkouts and updates ignore directories that only contain other directories, even if those sub-directories contain source files. Potential problem 2 (and the most likely one, IMO): unexpected options in effect. The -P option to checkout and update causes foo to be suppressed in cases 1.5 and 2. It tells CVS to suppress empty directories. That includes those that are truly empty, but also those that become empty once empty subdirectories have been suppressed. The -l option causes foo to be suppressed unconditionally, i.e. in all three cases (and even if foo does contain files directly, a fourth case not shown above). Perhaps one of these options is in the user's .cvsrc on some of the clients. On solaris we are using cvs version 1.11 and on linux we are using cvs version 1.11.2 Potential problem 3: the old CVS version. Not likely, since it's with the newer version on Linux that you're having problems. But many many bugs have been fixed since 1.11; even if an upgrade doesn't solve this particular problem, it's well worth doing. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: (newbie) Which is the actual cvsroot?/remote repository access
On Thu, Dec 19, 2002 at 04:28:43PM -0500, Mazza, Glen R., ,CPMS wrote: I'm confused which directory CVS considers as the root: /usr/local/cvsroot or /usr/local/cvsroot/CVSROOT? /usr/local/cvsroot -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: (newbie) Which is the actual cvsroot?/remote repository access
On Thu, Dec 19, 2002 at 04:34:57PM -0500, Larry Jones wrote: Mazza, Glen R., ,CPMS writes: 2.) Also, in trying to access a Linux CVS server from Windows NT, do I need WinCVS or another CVS client on my NT machine if using pserver authentication? (I would like to do CVS commands using Ant--I installed WinCVS, but I think WinCVS may be unnecessary for my purposes.) Yes, you need some kind of CVS client. True, but Ant might *be* a CVS client. I don't know for sure, having never used its CVS support, but it's a good possibility. Unlike make (but like CVS itself :-), Ant tends to slurp into itself any usually-external functionality that might be needed. An Ant mailing list might be a better place to ask about this. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Inter-dependent modules
Just to clarify (not contradict) what a couple of people said: On Sun, Dec 01, 2002 at 08:27:53PM -0800, Wayne Johnson wrote: You set up a module alias. If you have module A and B, both of which use module C, you can define a module X with contains modules A and C, and Y which includes B and C. X -a A C Y -a B C That only works if A, B, and C are all different directories. Each sandbox directory must be backed by exactly one repository directory. If you think about the contents of the CVS/Repository files, you'll see why this must be the case. But the tree hierarchies and names need not correspond. You can have sandbox-directory X contain only some of the files from repo-directory A. CVSROOT/modules can help you to semi-automate both of those things. The only thing you can't do is mix together *files* from more than one repo directory. That is, you can do this: Sandbox Repo X/* A/* X/C/* blah/common/* Or this: X/* A/* X/C/foo.js blah/common/foo.js (not present) blah/common/bar.js but not this: X/foo.jsA/foo.js X/bar.jsblah/common/bar.js On Mon, Dec 02, 2002 at 01:32:12AM -0500, Larry Jones wrote: Symbolic links to directories mostly work, although you may run into strange problems with some CVS commands. Symbolic links to files subvert the CVS locking mechanism and thus should never be used under any conditions. This refers to putting symlinks within the repo, or naming a symlink in $CVSROOT. Symlinks in sandboxes don't break, exactly -- but CVS pretty much ignores them, so you have to use some other tool, e.g. make, to maintain them. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS won't ignore removed files (remote will, local will not)
On Tue, Nov 26, 2002 at 10:17:49PM -0800, [EMAIL PROTECTED] wrote: CVS Version we are using on NetBSD platform. REMOTE: Concurrent Versions System (CVS) 1.11 (client/server) LOCAL:Concurrent Versions System (CVS) 1.11.1p1 (client/server) I'm trying to get rid of the following annoying message on a cvs update: cvs update: use `cvs add' to create an entry for toremove That it works in one case and not in the other could conceivably be a difference between client/server and local operation -- those have been seen before. More likely, though, it has to do with the different versions you're using -- especially 1.11, which is pretty old; lots of bugs have been fixed since then, and this might be one of them. Best would probably be to upgrade both client and server to 1.11.2, or to what's in CVS if you're feeling brave, and see if that solves it. Failing that, could you clarify which CVS version(s) were used for which tests? For the remote test, *both* the client and the server versions are needed. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problem with partially lost branch information
On Mon, Nov 25, 2002 at 02:05:00PM +0100, Karl-König Königsson wrote:
[...] a file with the branch tag set should have a
cvs version number with a zero in it; one of the adminstrative numbers.
I thus did this from the command line:
find . -type f -exec sh -c cvs -q log {} | grep
forv_ver1_020311-branch \; -print 2/dev/null |less
[...]
A rather brutal approach, you'll agree.
That's just the approach I'd have taken; but ouch! I bet it took
a *long* time. Try it this way instead:
cvs log | egrep '^Working file:|forv_ver1_020311-branch'
It produces similar output:
Working file: itp/build/b_wceupdate.bat
forv_ver1_020311-branch: 1.2.0.8
Working file: itp/build/foobar.bat
Working file: itp/build/b_wceupdate2800.bat
forv_ver1_020311-branch: 1.26.0.2
Advantages:
- You'll get the Attic files too, since cvs log with no
arguments DOES display deleted files (caveat; I know that's
true of 1.11.2.1, and I'm fairly sure it's been true for a
long time, but I can't say for sure that it's true of all
versions)
- It's *lots* faster. Your way forks at least a couple of
processes per file.
Disadvantage:
- There'll be spurious filename lines for files without the
tag, e.g. the foobar.bat line in the above sample
Anyway, the odd thing is that I
have now rid this structure of files with a wrong tagging but the error
still is there. I wonder: could there be files in the Attic that are
screwing up my directory structure?
Maybe. Or maybe you just need to repair the CVS state (fix the
CVS/Tag files or whatever it was) now that the underlying
condition has gone away (unless you've already tried that; you
don't say).
Furthermore: is my very-large-ax approach a good was of searching for
this error?
Absolutely. Just sub-optimally implemented :-)
It there are files in the Attic that are acting up, how am I
going to find them? Should I search on the raw RCS files in the
repository instead? How do I adapt my script to do that? (I'm not fluent
in RCS at all)
cvs log is a wrapper for rlog. So it'd be something like:
find $CVSROOT/itp -type f -name *,v | xargs rlog | egrep ...
Be warned that this will fail for pathnames containing shell
metacharacters, including spaces (those won't be a problem for
either your original approach or for my cvs log | grep one).
You can either work around that manually, or use GNU findutils as
I've described here recently (search the archives for -print0
[sic]).
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
Just Say No to the faceless cannonfodder stereotype.
- http://www.ainurin.net/ (an Orc site)
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to merge two repositories with out loss of log tags ?
On Fri, Nov 22, 2002 at 10:10:48AM +0530, Srinivas P Shenoy wrote: CVS/project which is a super set of project1 project2. I think you mean that the two old projects were independent of each other, containing different files; and the new super-project is to contain all of them (files from p1 + files from p2), something like: repository/ project/ old-project-1/ old-project-2/ Is that right? If so, just copy the ,v files from the two old repositories into a new repository, in the tree structure you want to end up with. (Copy instead of move, so that you still have the old repo's as backups :-) But if, instead, the two old repositories are variants of the same original code base -- i.e. each one contains different revision histories for the same files, so that what you want to do is, for each file, merge its two revision and tag histories -- that'll be a challenge, to put it mildly... The best bet in that case would probably be to: - import the current versions from project2 into project1, losing the version and tag history - do the obvious merge - keep the old project2 repository around for reference, but make it read-only so that people can't accidentally commit changes to it -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merging in CVS
On Fri, Nov 22, 2002 at 12:23:56PM -0500, MacMunn, Robert wrote: Thanks. Looks like merges must be difficult in CVS. A lot of manual work. Only when both new versions have changed the same area of the file. That is, if I edit line 100 and you edit line 120, there won't be a conflict. But if we both edit line 110, there will be. That's the theory. In practice, here is a partial list of things that can cause *lots* of conflicts: 1. Line-ending differences: your file has UNIX line endings; mine has Windows line endings (as if! :-). Then CVS will see *every* line as different, so the whole file will be one huge conflict. 2. If one (or both) people reformat the code -- run it through a code beautifier, change spaces to tabs or vice-versa, go through by hand and nicely line up abundant end-of-line comments, or whatever. Even though those changes don't have any effect on the program's behaviour, they're still changes as far as CVS is concerned, so they'll conflict with any other change (whether significant or also trivial) that another person makes in the same region of the file. 3. If someone wraps a block of code in an if statement, say, they'll indent it all an extra level. Again, the indentation change is a non-event as far as the compiler's concerned, but CVS can't tell that. 4. CVS keywords, especially $Log$. 5. Configuration files that need to be customized for each instance of the system (different sandboxes, different servers, etc.) All the routine per-instance customizations often conflict with substantive changes. XML seems to be particularly bad for this, I suspect because there's so much redundancy that the merge algorithm can get confused more easily than with other file types. Some of those situations should just be avoided: (1); $Log$; possibly other $Xxx$'s, though $Id$ can be useful enough to be worth putting up with the resulting merge conflicts. Others -- (2) and especially (3) -- are sometimes necessary, so the trick is to do them in such a way as to minimize the pain. If you know you're going to be making massive, trivial changes, like beautifying the whole project, get other people to commit their changes and go to lunch. Then you update, do your thing, and commit. That way they won't have done any work, so there won't be any conflicts. Things like changing the indentation on a large block of code are harder to schedule -- you do it based on need, not on would be an improvement -- so the resulting conflicts just kind have to be lived with. (5) can be greatly improved by going to a template-based approach. For the project I'm currently on, I whipped something up in Perl to do autoconf-like macro substitutions on the XML config files. If all the per-instance customizations -- host names, port numbers, etc. -- are done by that Perl script, and only the uncustomized templates are stored in CVS, the many pointless conflicts will go away, and the only remaining conflicts will be between groups of *substantive* changes. A special case of (2) is files that are written with the aid of smart tools -- XML editors, IDE's, and the like. Then you don't necessarily have control over the precise formatting; the tool might change things in ways you didn't expect. Similarly filled text -- add a word, and the rest of the paragraph might get reflowed. Not much that can be done about those cases, unless you (and your colleagues) are willing to forego the spiffy tools... In summary, merge conflicts are indeed a problem. Worse in some situations than in others, but usually manageable, by which I mean, reducible to the level of annoyance rather than major productivity drain. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Branches and Dates
On Tue, Nov 19, 2002 at 10:16:47AM -0500, Larry Jones wrote: You need to specify both the branch and the date. Unfortunately, not all CVS subcommands allow both -D and -r at the same time [...] Why not? I could see the reason being any of: a. because they don't always make sense together b. a thing that could be fixed simply if someone were motivated c. a thing that could be fixed, but only with difficulty d. a thing that should be fixed, but cannot be, due to insurmountable internal problems or even different situations for the different subcommands. Please don't take this as criticism, Larry; that's not my intent! I'm merely trying to draw you out on the reasons. It'd be good to have that bit of your expertise on the record, in case someone tripping across this thread in the archives decides it's a project worth taking on :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: view a file in CVS without it messing with my /CVS/Entries info.
On Mon, Nov 18, 2002 at 07:04:11PM -0500, Schoep, Grant @ STORM wrote: I want to look at a particular revision of a file, without having it change anything in my local directory. Usage: cvs update [-APdflRp] [-k kopt] [-r rev|-D date] [-j rev] [...] -p Send updates to standard output (avoids stickiness). -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Retrieving deleted file from the Attic
On Wed, Nov 13, 2002 at 04:59:49PM -0800, Jason Yeung wrote: I was wondering if it's possible to recover a file that is in the Attic directory? cvs update -j1.4 -j1.3 foo.c# 1.4 is the deleted rev.; 1.3 is the one # preceding it. The odd-looking order of the # -j's is intentional, and important. cvs commit -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
