Re: [New CVS user] Best config?
On Mon, May 15, 2000 at 09:57:47AM -0400, Noel L Yap wrote: The problem with ssh is that it requires a login shell into the server (please correct me if I'm wrong 'cos I've been looking for a way around this). The user needs an *account* on the server; they don't need to be able to log into it. I haven't tried this, but you should be able to do something like: - Create a login "fbaggins" on the server - "*" out the password field (in /etc/shadow or wherever) so that the account cannot be logged into - In sshd_config, set: RhostsAuthentication no RhostsRSAAuthentication no These prevent any stray .rhosts that may creep onto the server from providing a way in -- even from an RSA-authenticated client machine. RSAAuthentication yes This allows use of the key-pair you're about to create. PasswordAuthentication ? "no" is safer, but "yes" is perhaps more convenient for those who are supposed to have shell access to the server. This is a policy decision for the box's sysadmin. - Create an SSH key pair for fbaggins; give Frodo the private key from this pair install on his client machine - On the server, in ~fbaggins/.ssh/authorized_keys, put the public key from the above key pair, with the option: command="cvs server" This ensures(?) that the only thing anyone can do with the fbaggins account is CVS commands. Actually, you might not need to create a login for every user. Just a single one, set up as above, should do. Give each user their own key-pair, and put all their public keys in the cvs account's authorized_keys -- all with `command="cvs server"' options of course. Potential problems: - That "ensures(?)". I gather that it's undependable to use an account's .profile for security restrictions, even with the permissions locked down tight; I'd want to look at SSH a bit carefully to convince myself that the "command=" option doesn't suffer similar weaknesses. - Frodo, having lost a finger to his famous adventure with a magic ring, will want nothing whatsoever to do with your $@*!# magic key :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / to me, Charlie Brown represented the courage to be sincere in the face of ridicule. he was NOT a loser. thank you, Mr. Schulz. - Robert C. Mayo
Re: CVSROOT/passwd enhancements
On Wed, May 24, 2000 at 03:54:11PM -0400, Avi Green wrote: When I first studied Unix a few years ago, I read that one should use an asterisk to denote an impossible (i.e. unusable) password because asterisks are not in the set of ciphertext characters used by the Unix password encryption scheme. Shouldn't make any difference. The output of any given system's crypt() function is a constant-length string. If the password field is a different length, then no cleartext string can possibly encrypt to it. Also, "NP" is often used to denote an impossible password. Which is why this is safe. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / to me, Charlie Brown represented the courage to be sincere in the face of ridicule. he was NOT a loser. thank you, Mr. Schulz. - Robert C. Mayo
Re: CVS Delete All Files
On Tue, Jun 06, 2000 at 11:47:57AM +0200, Fredrik Liljegren wrote: find . -type f -print | grep -v CVS | xargs rm xargs "cvs rm" ..I'm not totally sure how to execute two commands on the stdin-files, but something like that should do. This won't work. It's parsed as: (find ... | grep ... | xargs rm) xargs cvs rm The pipeline feeds into the first xargs; the second reads from the tty. Putting in the parens: find ... | grep ... | (xargs rm xargs cvs rm) still wouldn't work; the first xargs would consume all the input, and the second wouldn't see any. The only way I can think of to do this is to save the list in an intermediate buffer. Fortunately, this particular case is easier: find . -type f -print | grep -v CVS | xargs cvs rm -f (No quotes, by the way.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / to me, Charlie Brown represented the courage to be sincere in the face of ridicule. he was NOT a loser. thank you, Mr. Schulz. - Robert C. Mayo
Re: PVCS CVS importer?
On Wed, Jun 14, 2000 at 03:56:06PM -0500, Robert Bresner wrote: [mixed CVS/PVCS project (one team using each, with nightly merges] In my leetle mind, I imagine some Perl script running at night, which would (ugh) file by file pull down the latest PVCS and CVS versions, merge them, (this is starting to sound more and more like a mad scientist pipe dream to me as well) and return them to their respective repositories. A perl script *can't* do the entire merge. Only a human can resolve conflicts. But you're right, it could do some of the grunt work. This would be a problem even with two disjoint CVS repositories, by the way; this part isn't PVCS's fault. Politics, you see, is driving this right now, and I, being the cog, need to find a way to make it work, or in very lay man's terms explain to the parties involved exactly why and how this cannot be done. How often do you need to synchronize? If daily, I strongly suspect that indeed it can't be done. If weekly or less, treat their work as third-party source, and import it onto the vendor branch. (See "* Tracking sources:: Tracking third-party sources" in the manual.) Synchronizing looks something like: - They send you a snapshot of their latest and greatest - You "cvs import" it - You do a merge, resolve conflicts, compile, test, etc. - You ship them what is now your latest and greatest (which includes both teams' changes since the last synchronization) - They merge this into their code base. How? Good question. If PVCS provides help with this, great; if not ... that's a concrete (ie. not merely philosophical) argument against using it. It might make sense to have your development on a branch as well, and reserve the trunk for merging. But I don't know; maybe this would cause more problems than it solves (especially, getting the results of a merge back onto your team's branch). What do other people think? Tag like mad, before and after every merge. Mostly this will seem like a waste of time and effort, especially when you're under pressure to deliver the next snapshot -- but sooner or later you'll be very glad you did it! So far I've failed, because I don't know enough about PVCS, and the PVCS guy doesn't know enough about CVS. The knowledge transfer we've had thus far tells me that PVCS is not right for this project at all, and the tells the PVCS guy that CVS is not right for the project. Of course :-( I suspect that neither is intrinsically right or wrong for the project per se ... but each is wrong for the other team's development style. Not too surprising; each company will have picked a tool that suited their way of working, or adapted to the tool's way of working, or most likely some of each. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
Re: Files created on Branch
Which version of CVS? I just tried this using 1.10.8 and it worked fine. On Thu, Jun 15, 2000 at 01:58:39PM -0400, Kevin C. Castner wrote: I have files that were created on a branch (Create the file) cvs co -r branch_name doc cd doc touch index.htm cvs add index.htm cvs commit index.htm Now I try to merge the file back to the main trunk. cd .. rm -rf doc cvs co doc cd doc cvs update -j branch_name cvs commit index.htm CVS then gives me the following error: cvs server: cannot add file `index.htm' when RCS file `/export/home/cvs/netops/doc/index.htm,v' already exists cvs [server aborted]: correct above errors first! -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
Re: .trunk patch refinement
I'm well aware that bumping trunk revisions to 2.x or greater is pretty useless, and that tags are the right way to go, especially since after you do it, newly-added files will still get 1.x revisions. However... On Mon, Jun 19, 2000 at 05:01:45PM -0400, Greg A. Woods wrote: However people should *not* ever be doing such silly things -- there are more corner cases than just this one whre they can get into trouble! ... I wasn't aware that it's actively dangerous, as Greg seems to be saying. If so, is there any reason to keep it? Why not just make commit's -r option go away? [ On Monday, June 19, 2000 at 17:12:42 (+0100), Mike Little wrote: ] Would '-r1' work if some previous cvs admin had updated vast numbers of the trunk revisions to 3.x (presumably when version 3.0 of the product was released)? "say -r1 when you mean latest-on-trunk" is a kludge, to work around the lack of ".trunk". That it fails on trunk revision 2.x isn't a corner case in CVS; it's a limitation of the kludge. The man's offering to obviate this kludge with a correct solution; what's all the grumbling about? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
Re: Repeatedly merging from branch to trunk
On Wed, Jun 21, 2000 at 09:32:03AM +1000, Brian Collins wrote: OK, so, if on the branch the change had looked like this: Line 2 on the branch Line 2A and on the trunk it had looked like this: Line 2 on the trunk Line 2A then adding "Line 3" on the branch after "Line 2A" would *not* have resulted in a conflict? Correct, except that CVS might require more than one identical line in between (eg. 2B, 2C, and 2D) to be confident that it had put "Line 3" in the right place. Of course, the problem would still be lurking; a year from now, someone would end up making a change too close to "Line 2", and would trip across it. The Right Thing(TM) would probably be to collapse (ie. "merge and forget") the branch and start a new one, rather than doing multiple merges from the existing one -- but I'm not quite sure how to do this in a context of ongoing bug-fixes to the previous release. The expedient thing, if the "Line 2 on the trunk" changes are fairly localized, might be to check them in on the branch, so that there's no longer a disagreement. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
Re: Empty directories
On Sun, Jun 25, 2000 at 08:22:50PM -0700, W. Reilly Cooley wrote: If you want the directories to remain, but remain empty, put in a file called .cvsignore with the contents of '*'. You can call the file anything you want, and its contents are irrelevent. All that matters is that the directory not be empty. (One convention is to create an empty file called ".keep_me", although I usually have the file contain a note telling people not to delete it.) That being said, the .cvsignore suggestion often turns out to be what you want. If the directory is to contain logs, temp files, or other things that are not intended to be CVS-tracked, you'll need a .cvsignore anyway. Since that will suffice to make the directory non-empty, you won't need a .keep_me file as well. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
Re: Diff / Status problem
On Wed, Jul 05, 2000 at 10:01:38AM +0200, Matthias Kranz wrote: Ok, now I finally got your point. That the two files have the same timestamp is not the problem, but the fact, that your copying preserved the original timestamp of subdir1/File1.hpp. If you use a normal copy command or just edit a file, the new timestamp will differ to that one in CVS/Entries. On UNIX, that is. Windows preserves the timestamp when you copy a file (as did DOS before it, and, if I recall, as does MacOS). The rationale is presumably that the timestamp says when the *data* last changed, regardless of where that data happens to reside. Which actually makes a lot of sense; to me, it's UNIX's default behaviour that's counterintuitive (and I've been using UNIX since long before I touched either of the others). On Wed, Jul 05, 2000 at 04:11:10AM -0400, Leeuw, Guus (G.) wrote: Uhoh this might be because of the SAMBA link that you are using. Much as I agree with the arguments for using CVS client/server instead of with a remote-mounted repository, I think Samba is a red herring in this case. The problem is due to a mismatch between CVS's assumptions and the client O/S's file-copy semantics, not to any mis?-configuration of CVS. Therefore: This, really, isn't a problem of CVS! I beg to disagree. I've even been bitten by this once or twice even in a pure-UNIX context (I can't remember the details, I'm afraid.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
Re: [cciug] general makefile (and script) style rule
On Fri, Jul 28, 2000 at 02:38:12PM -0400, Laine Stump wrote: David Boyce writes: CLEARTOOL := C:/Progra~1/Rational/ClearCase/bin/cleartool.exe That can't be guaranteed to be correct across multiple machines. Or indeed within the same machine, if you ever have to do a full restore -- which might assign "C:\Program Files" a different 8.3-name if "C:\Program ABC" also exists on the tape. As I understand it, there's no way to guarantee at restore time that a given long-name will be given the 8.3-name it had before (since the API provides no way to specify the mapping). -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
Re: CVS pids and the pids of its kids
On Thu, Aug 03, 2000 at 01:37:19PM +1200, Chris Cameron wrote: On Thursday, August 03, 2000 11:57 AM, Laird Nelson [SMTP:[EMAIL PROTECTED]] wrote: That is, the fact that I'm seeing nothing grabbing a pid inbetween the fork and exec calls doesn't mean that something COULDN'T grab a PID at that point. SO I really shouldn't rely on the delta being 3 at all, should I. Absolutely not! Even if this were reliable, it would still be highly fragile. It would break if a new version of CVS added or deleted a process. It would even break if you changed your commitinfo or verifymsg to invoke any subprocesses. Then again, if this is Linux, I don't know how similar to the commercial flavours of Unix it is in this regard. Similar enough. fork() and exec() are still distinct system calls; the user-space code between them is still a critical section. On Wed, Aug 02, 2000 at 07:18:16PM -0400, Laird Nelson wrote: Doesn't a fork and exec result in...two addi... ...tional PIDs? No, just one. aha, but the second cvs (the one that's exec'ed) is then invoking my loginfo script so that's why loginfo getppid() returns commitinfo.getppid() + 3. Perhaps it's like this: Original-cvs=1000 | ++--+ || | commitinfo=1001 verifymsg=1002child-cvs=1003 | loginfo=1004 with processes 1000 and 1003 being the ones seen by the various getppid() calls. But perhaps that's what you meant all along... Anything that depends on counting PIDs is unsafe; anything that depends on parsing ps(1) output is unportable; any of these is pointless if CVS moves to a different algorithm for generating the temp-dir name (eg. if it starts using mktemp(3)). On Thu, Aug 03, 2000 at 12:17:50AM -0400, Donald Sharp wrote: Have a control file that tracks directory names based on the original cvs invocation pid. Why not make the original cvs (pid 1000 in my example) export the temp-dir name into an environment variable? The variable would be scoped correctly, by definition. And there would be no reliance on PIDs. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
Re: Next CVS release? (1.10.9?)
On Thu, Aug 03, 2000 at 11:01:54AM -0400, Larry Jones wrote: CVS has traditionally not differentiated between new feature releases and bug fix releases, both are just interim releases. Are there plans to so differentiate in future? There should be, IMO. Especially since it has long claimed to differentiate. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
Re: Next CVS release? (1.10.9?)
On Thu, Aug 03, 2000 at 03:10:33PM -0400, Larry Jones wrote: The only differentiation is between official releases (1.9, 1.10, etc.), which are stable and well tested, and interim release (1.10.1, 1.10.2, etc.), which may not be as stable and are not as well tested. I was speaking just of interim releases which may contain bug fixes, new features, or, most often, some of each. I don't see any pressing need to change that in the future. I believe I do see a need, or at least a strong want (though I'm willing to be corrected). Why is it so long between official releases? I'm not sure, but here's one possibility: it takes quite a while to test a version well enough to declare it stable enough to be worthy of official-release status (this part's no guess :-) But the world won't hold still; people keep committing new (stability-risking) code, effectively forcing the beta-test period to start over. And indeed, the people in a position to declare a feature freeze are themselves too anxious to squeeze in one more thing first. If this is indeed the problem (or even a significant fraction of the problem), it argues for separate "development" and "stable" branches, as Pavel Roskin suggested: On Wed, Aug 03, 2000 at 16:57:20 -0400, Pavel Roskin [EMAIL PROTECTED] wrote: However, I believe that the 1.11 should be the branch point. The stable branch would be used for high-priority fixes only. Developers on the head branch should feel free to make radical changes. and as other open-source projects have already discovered. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
Re: CVSROOT folder and files under projects missing!!!
On Fri, Aug 18, 2000 at 02:04:43AM -0700, Veronica Lee wrote: 1) After we moved the repository over, some files are missing. At a closer look, these files were not missing. Instead, these files were changed from, e.g. CommunicationsManager.java,v to CommunicationsManager.java,v0100444. This made these files invisible to CVS. I moved the repository over by taring the entire repository and ftped it over to the new box. There are about 100+ files in this repository but only 6 of them were impacted across 5 different directories. What do you think caused this? Is this an existing bug? Yes -- in your "tar". I have a particular tar file (a software distribution) that does this when I unpack it with Solaris tar (from Solaris 2.6). When I unpack the same file with GNU tar, it instead lops off the last character of the filename. Eg.: Solaris tar gives me: jrun/jsm-default/services/jws/htdocs/jsp/apidocs/com.livesoftware.jrun.plugins.ssi.ITagableData.html0100644 GNU tar gives me: jrun/jsm-default/services/jws/htdocs/jsp/apidocs/com.livesoftware.jrun.plugins.ssi.ITagableData.htm This only happens with pathnames exactly 100 characters long, as stored in the tar file. Looks like a boundary condition that both tar's get wrong in different ways. (Or else it's the tar that *wrote* the file that got it wrong...) 2) Very recently a bigger catastrophe occurred. The entire CVSROOT folder was gone, which made the entire repository inaccessible. Moreover, 10+ files were missing. I can't offer much here except to say that this is not something I've *ever* seen CVS do! Actually, there's another bug in GNU tar 1.12 (fixed in 1.13), that is exercised by the same tar file as mentioned above. I doubt it's responsible for your problem (especially regarding CVSROOT), but I'll describe it just in case. GNU tar 1.12 also screws up extracting pathnames strictly greater than 100 characters long: it loses the directory portion, and puts the file in the directory from which it was run. Eg. the file which should be extracted to: jrun/jsm-default/services/jws/htdocs/jsp/apidocs/com.livesoftware.jrun.plugins.jsp.JSPAbortException.html instead gets put in: ./com.livesoftware.jrun.plugins.jsp.JSPAbortException.html -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues
Re: cvs init: cannot exec ci: No such file or directory
On Fri, Aug 18, 2000 at 10:28:21AM -0400, Jim TheVoice wrote: I use CVS 1.9 on a Sun e450 with Solaris 8 and when I use this command, I got an error... [...] cvs init: cannot exec ci: No such file or directory cvs [init aborted]: failed to check in /src/cvs/CVSROOT/loginfo CVS can't find the "ci" program (part of RCS), which it needs as a helper. But the solution is *NOT* to install RCS; it's to get the latest version of CVS, which doesn't need external helpers, and has lots of other stuff fixed as well. ftp://ftp.cvshome.org/pub/cvs-1.10.8/cvs-1.10.8.tar.gz -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues
Re: Minor client/server bug
Well, I'm not a CVS developer, but here's my $.02 anyway. On Tue, Aug 22, 2000 at 11:12:34AM -0600, Derek R. Price wrote: "KOIE Hidetaka ($B8q91QN4(B)" wrote: From: "Derek R. Price" [EMAIL PROTECTED] Subject: Minor client/server bug Date: Wed, 9 Aug 2000 14:29:34 +0900 (JST) | When commands are run that instruct you to rerun cvs, the name of the | executable on the server side is printed rather than the name on the | client side I have made a patch. Summary: [the client sends its name to the server, for inclusion in error messages] I was looking at this and it doesn't look like the right fix - there's really no reason for the server to know the name of the client executable. As an aside, I don't actually see what's so bad about the server knowing the client's name for display purposes, as long as it never actually tries to *run* the client. (Note, it doesn't have to know the path to the executable; in one common case, it would make sense for the client to report its name as "WinCVS", not as "C:\progra~1\whatev~1\wincvs.exe".) I researched it a little and I see two possibilities which leave the error message intact: 1) Have the client assume from the "Checked-in" server response on added files and the "Remove-entry" server response on removed files that this message needs to be printed. 2) Expand the 'MT' piece of the client/server protocol [...] so that the client knows the message type and which variables to parse for then constructs a message on its end (including the local executable name, of course). The reason I ask is that it seems to me that the precedent is to go with #2, Given that the MT mechanism exists, however, it seems to me the best approach. This is exactly what it's for, after all. I disagree about sending only the variables and letting the client construct the message, though. Judging (only) by cvsclient.texi, the precedent is to construct the entire message on the server, out of a combination of variables and "MT text" constant strings. More important than being the precedent, this approach means that the user will get a somewhat-useful message even if the client is too old to recognize those particular MT tags. On the other hand, of course, is that your approach works better for windowing clients. The client can assemble the variables with its own text into a message that makes more sense in context: instead of "type `cvs update -j...'", it can say "choose `update' from the XYZ menu, then...". But the two aren't necessarily incompatible. With the existing scheme of "MT text"s interspersed with variables, the client could always ignore the former and supply its own. One simple protocol extension would cover all the possibilities, it seems to me. Add this MT tag, valid in any context: MT cvsprogram cvs The server always sets the DATA to the string "cvs". If the client recognizes the "cvsprogram" tag, it ignores the DATA and prints whatever user-friendly name it wants to call itself. Otherwise, of course, it just spits out the DATA as raw text, but the server's choice of data makes the resulting message still somewhat sensible. [...] letting the server be the source of all error messages which aren't due to a client problem (e.g. local file permissions, unavailable network, etc.). This makes sense to me, from the perspective that a "stupid client" means that much server operation is invisible to the client, a client only needs to know things it can be commanded to do directly, e.g. merge files, set sticky tags, or remove an entry, leading to clients which require upgrades less frequently despite possibly frequent server upgrades. Agreed. Having the client intuit when a message is necessary, or what its contents should be, is ugly, fragile, and hard to extend. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues
Re: File timestamp after commit.
On Fri, Aug 25, 2000 at 03:21:26AM -, [EMAIL PROTECTED] wrote: Where do I look for the culprit [timezone/dst -- file timestamps being off by an hour]? My windows 95 machine reports correct NZ time of day (but may have incorrect GMT :( ) To my knowledge, Win9x doesn't distinguish -- it maintains its clock in local time. But its timezone setting may be relevent anyway. Look in the "Date/Time" control panel; make sure both the timezone and DST settings are correct. The server machine reports correct NZ time of day (but may have incorrect GMT :( ) If the server is a Unix box, here's how to see its internal time setting: $ TZ=GMT0 export TZ $ date (NZ currently GMT +1100, Nominally GMT +1200) You consider summer to be the nominal time, and winter to be an hour behind? In the northern hemisphere, we consider winter to be nominal, and summer an hour ahead. Hmm, this seemed weird enough that I looked into it further. Looks as though NZ is currently, and nominally, GMT +1200; summer time is GMT +1300. That's true of Auckland, anyway. If your server is labouring under the same misconception as your posting, that could explain some things. (See http://sandbox.xerox.com/stewart/tzconvert.cgi or www.mylocaltime.com -- but, ironically, the latter's idea of the current time is *way* off.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues
Re: Antigen found =*.pl file
(Mr. Davis, I'm sending this to you as Technical Contact for the alcoa.com domain. If you don't maintain the email scanner, please forward this to the person who does. Thanks.) [EMAIL PROTECTED] is a mailing list on which Perl scripts are often discussed. These are not malicious; they are perfectly reasonable adjuncts to the CVS source-control system which is the focus of the list. We are getting more and more tired of these little nuggets of wisdom appearing in all our inboxes every time someone posts a Perl script to the list. They are most annoying, and accomplish nothing beyond telling us what we already know. Therefore, please cause your email scanner NOT to CC the [EMAIL PROTECTED] address on these messages. Thank you. On Mon, Aug 28, 2000 at 02:27:56PM -0400, ANTIGEN_NA-ATC wrote: The following message is from the Alcoa Exchange Virus Protection System. An attempt to send the File run-autoconf.pl matching the filter =*.pl for a potential Virus from [EMAIL PROTECTED] The file was Deleted. The message was, "A truely ugly hack...". Please ensure that your PC has Anti-Virus protection with current definitions to detect and clean Viruses. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues
Re: What is Cederqvist?
On Mon, Sep 11, 2000 at 04:59:46PM -0700, W. Reilly Cooley, Esq. wrote: On Mon, Sep 11, 2000 at 04:25:06PM -0700, Matthew Berney wrote: Pardon my ignorance, but what is the Cederqvist? Is it a user manual, some arcane CVS lore? I have seen many references to it here on the CVS digest. cvs.ps in the CVS source (and probably binary) distributions. In other words, the authoritative CVS documentation that comes with the package (doc/cvs.texinfo and all its derived formats). Why not just refer to it as such? To call it "The Cederqvist" instead implies that it is, as Mr. Berney suggested, "some arcane CVS lore". It may acknowledge Per's important contribution at some time in the distant past, but in the present it's merely confusing to those who are not in the CVS "club". Indeed, I'm glad to have someone finally confirm my theory that "The Cederqvist" and cvs.info are one and the same -- and I've been using CVS since version 1.2 or 1.3. Technical terminology is one thing; jargon for its own sake risks the charge of willful obscurantism. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues
Re: [Info-cvs] CVS for MVS: Configure question
[EMAIL PROTECTED] wrote: I am working on the port of CVS to MVS. [...] As I see it, we need to modify Configure.in (which generates configure) so that configure tests to see if this is a MVS system, and to append ../mvs/libmvs.a to @LIBS@. Any suggestions on where and how to do this? Am I even looking in the right place? There are aspects of this problem that apply in general to doing MVS ports of Autoconf'ed software. Detecting an MVS system certainly fits into this category, and some of the specific portability fixes (eg. stuff that's now in libmvs.a) might as well. The best solutions to these more-general problems will be the ones that fit best, not into the existing CVS framework, but into the existing Autoconf framework. That way, other projects will benefit from them too (and, with luck, CVS per se won't need any specific code to deal with them). Thus, it'd probably be worth asking over on the autoconf mailing list, [EMAIL PROTECTED] (the admin address is probably [EMAIL PROTECTED], but I can't remember for sure.) On Wed, Sep 20, 2000 at 02:02:49PM -0400, Derek R. Price wrote: In general principal, look for things in this order: 1) A general standard already defined and being used, such as POSIX, SYSV, or _STDC_. 2) A autoconf macro that already does what you want 3) Some test code you could run to find out how your compiler works. If you have to do (3), better to write it as a new autoconf macro, and submit the results to the autoconf project (again, this is more broadly useful than hard-coding it in CVS's configure.in). If this is something that is really MVS specific and should stay that way, then the solution I found in the ssh 2 code from Communications Security might be more appropriate. It just uses uname, $host and $target (there's some cross-compiling code at the beginning of the document to set those too) to set some lib and compiler variables. See the "Manual Configuration" section of the Autoconf manual (it's listed in the top-level menu of autoconf.info). -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff generating unuseable patches ?
On Wed, Oct 18, 2000 at 05:59:06PM -0700, richard offer wrote: I'm trying to generate a large patch that includes new files [...] But for the new files it starts creating files called /tmp/cvsx instead of the files in the directory ? ie looking at the diff. Index: drivers/block/audit.c === RCS file: audit.c diff -N audit.c *** /dev/null Tue Aug 29 14:22:17 2000 --- /tmp/cvsQt9R2X Wed Oct 18 17:09:29 2000 CVS inserts the "Index:" line specifically so that this will work. Well, it used to work, until the following change was made to patch (this is an excerpt of a much longer ChangeLog entry): 1997-06-12 Paul Eggert [EMAIL PROTECTED] * pch.c: Ignore Index: line if either old or new line is present, and if POSIXLY_CORRECT is not set. So, you can make it work by setting POSIXLY_CORRECT in your environment when you apply the patch. Paul, just out of curiosity, can you still recall what this was about? Given that it breaks "gdiff -N"-generated patches (whether from CVS or otherwise), it must have been intended to fix something else. Any idea what? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Starting New Repository - Vendor Branch - Bug/Feature? (was: CVS IMPORT Help)
letely, as CVS tries its best to do. It's only there because the underlying data structure (which, recall, was borrowed from RCS, not invented for CVS) requires it -- you can't have a branch that isn't rooted anyplace. "Fred W." [EMAIL PROTECTED] writes: Prior to making changes I want to tag the current version as 'REL_1_0 ' . Assume I only have one file 'test.txt'. When I look at the log it shows the tag on 1.1.1.1 of the file. How can I tag version 1.1? You can't, and you don't want to. I hope I've convinced you that CVS really is doing the right thing here. I believe this suggests the answer to the original post is that if he makes a tag on the working version of his files, it will be applied to the trunk and not the vendor branch. Depends what the working version consists of. In the example cases above, suppose you type "cvs update -A; cvs tag mytag". That tag will be applied as follows: configure.in1.4 NEWS1.1.1.2 COPYING 1.1.1.1 ie. to the latest-and-greatest revision of each file, whether that's the vanilla one from the distribution, or the one you've modified locally. (Strictly speaking, "cvs tag mytag" just tags whichever revisions are in the sandbox; it was the preceding "cvs update -A" that ensured that the sandbox contained all the latest-and-greatest revisions as described above). -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Bogus address on info-cvs list (was: Mail message not delivered)
We've been getting bounce messages like this for a few days on [EMAIL PROTECTED] Looks as though you should unsubscribe this person (after, of course, having verified that the bounce messages are genuine :-) Thanks much. - Forwarded message from [EMAIL PROTECTED] - Subject: Mail message not delivered From: [EMAIL PROTECTED] Date: Thu, 23 Nov 2000 12:50:11 -0600 To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0 List-Help: mailto:[EMAIL PROTECTED]?subject=help List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: http://mail.gnu.org/mailman/listinfo/info-cvs, mailto:[EMAIL PROTECTED]?subject=subscribe List-Id: Announcements and discussions for the CVS version control system info-cvs.gnu.org List-Unsubscribe: http://mail.gnu.org/mailman/listinfo/info-cvs, mailto:[EMAIL PROTECTED]?subject=unsubscribe List-Archive: http://mail.gnu.org/pipermail/info-cvs/ Your message, titled: Re: single-bit errors that you sent to [EMAIL PROTECTED] has not been delivered. The user at that address is no longer available. The following alias addresses are also no longer available. [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Please update your address book Thank You ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs - End forwarded message - -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: rollback/revert changes?
On Thu, Nov 23, 2000 at 08:16:49PM -0500, Nick Papadonis wrote: Anyone know of a better/easier way of rolling back to a previous file version other then the following sequence: cvs update -rver file.c mv file.c file.c.older cvs update -A file.c mv file.c.older file.c cvs commit -m "reverting to prev version" file.c Yeah: cvs update -p -rver file.c file.c cvs commit -m "reverting to prev version" file.c Still a kludge, but a shorter one :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS access through a firewall
On Fri, Nov 24, 2000 at 10:21:08AM -0800, Stephen Rasku wrote: Is it possible to configure the CVS client to talk to a different port than the default ssh port (e.g. possibly through a CVSROOT variable.)? It's SSH that needs to be configured. In /etc/ssh_config (or whatever it's called on your system), put a "Port" directive in the entry for the CVS server. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS access through a firewall
On Fri, Nov 24, 2000 at 11:55:15AM -0800, Stephen Rasku wrote: Eric Siegerman wrote: On Fri, Nov 24, 2000 at 10:21:08AM -0800, Stephen Rasku wrote: Is it possible to configure the CVS client to talk to a different port than the default ssh port (e.g. possibly through a CVSROOT variable.)? It's SSH that needs to be configured. In /etc/ssh_config (or whatever it's called on your system), put a "Port" directive in the entry for the CVS server. But how do I configure the client to talk on that port? Can I use CVSROOT or CVS_RSH (or something else?) to specify what port to use? That's what my suggestion *is* doing. (Unless I'm very confused. I admit I've never tried this with CVS, and what ssh hacking I did was a while ago, so I'm refreshing my rusty memory from the docs.) Note I said "ssh_config" not "ssh*d*_config". /etc/ssh_config, like ~/.ssh/config, contains configuration for the ssh client. You use it to specify, for each server you connect to, any options specific to that connection. So you don't do anything special to CVS, just give it a server host name as usual (in CVSROOT, global -d option, .../CVS/Root, or whatever). But, assuming your server is called foo.bar.com, you put something like this in /etc/ssh_config: Host foo.bar.com Port [any other options you need] -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Changing the log message
Using a Bourne'ish shell: cvs admin -m1.2:"New message" file.c Not sure how to do it in C'ish shells. On Tue, Nov 28, 2000 at 05:29:54PM -0600, Olaf Meding wrote: How can I specify a carrige returns in the change log message command below? cvs admin -mr1.2:"New message" file.c Thanks much for your help and time. Olaf ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multiple developers in one work area
On Thu, Dec 14, 2000 at 03:46:15PM -0800, Parand T. Darugar wrote: We would like to have those multiple developers access the same directory of source code, as opposed to each having their own working area. It sounds as though you already understand that this is completely counter to the way CVS wants to work, so I won't belabour the point. The reason behind this is that everyone needs to use the same web server for testing, and hence the same working area. Why must they use the same web server? What we do is give everyone their own WWW server and JRun instance, both tied to their personal CVS sandbox (indeed, in our shop, the word "sandbox" has come to signify not just the CVS working directory, but that plus its associated server instances). Besides going along with the CVS paradigm for its own sake, this gets us the advantages that paradigm was designed for in the first place: - concurrent editing - each developer can test their own work in isolation (since each has their own WWW server to test it on) We intend to set up separate integration sandboxes, and institute some procedures for using them, but that hasn't really happened yet -- too busy developing :-/ I wrote a Perl script to check out a new CVS working directory, create a new JRun instance, and tie them together; unfortunately, the configuration for Netscape's WWW server is weird enough that I didn't feel comfortable automating it, so that step is still done manually. With Apache, this part could almost certainly be automated as well (note that it's better to give each user their own Apache instance, not just a virtual server; that way they can edit their Apache configuration, and start and stop their server, without breaking other peoples' environments). On the development machine, we divided the IP port space into 200-port blocks starting at 1; each sandbox is allocated one block of ports. A few of the ports are predefined (with the offsets being, hopefully, somewhat mnemonic): BASE+0 = JRun admin BASE+1 = Jrun JCP (ie. the servlet server) BASE+80 = HTTP server BASE+99 = Java RMI but the rest are free for the developer to use however they like. This has the fringe benefit of offloading port administration from the sysadmin: if a programmer wants to run something that works over IP -- a network-aware Java debugger, a networked game, or whatever -- they don't have to bug the sysadmin for a free port number. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Removed a file, now cannot add it back...
On Mon, Dec 18, 2000 at 11:48:36AM -, Ross Burton wrote: Several months ago we removed a file from the CVS tree, and now we are trying to check a file with the same name back in again. 1038 percival:Keil | cvs update # Normal output deleted 1039 percival:Keil | cvs add standalonegeneva.lnp# Normal output deleted 1040 percival:Keil | cvs commit cvs commit: Examining . cvs commit: cannot add file `standalonegeneva.lnp' when RCS file `/home/cvsroot/Apps/Geneva/Bootstrap/Keil/standalonegeneva.lnp,v' already exists From the error message, it looks to me as though the RCS file somehow didn't get moved to the Attic when the file was originally deleted. I've seen this happen on occasion (not sure with what version of CVS, or any of the other circumstances, so I can't really formulate an official bug report). To fix it: # Be *very* sure this file *really* was deleted from CVS # (eg. be sure the latest revision on the trunk has state # "dead"). If it was, then: cd /home/cvsroot/Apps/Geneva/Bootstrap/Keil mkdir Attic # if it doesn't already exist mv standalonegeneva.lnp,v Attic/standalonegeneva.lnp,v -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Vendor branches, tracking sources and creating patches
On Wed, Dec 20, 2000 at 05:37:44PM -, Ross Burton wrote:
[they need to use CVS to track the GCC distribution while
making local changes]
I think this can be achieved if we take, for example, gcc 2.95.2 and
import into our tree as such:
tar zxvf gcc-2.95.2.tar.gz ; cd gcc-2.95.2
cvs import -m "Import of GCC 2.95.2" gcc GNU GCC_2_95_2
We can work with this, adding files and editing and files which need
to be changed. When we need to make a diff between all of our changes
and the original 2.95.2 source, I run:
cvs rdiff -r GCC_2_95_2 -r HEAD gcc
I'd recommend setting a release (ie. non-branch) tag when you do
this (also, use "-u" to make a patch that the GCC maintainers can
actually use):
cvs rtag -r HEAD patches-submitted-20001220 gcc
#
# Don't use "-r HEAD" again in the "rdiff"; use the tag
# you just created. This closes a race condition;
# someone might commit a new revision between these two
# commands.
#
cvs rdiff -u -r GCC_2_95_2 -r patches-submitted-20001220 gcc
That way, the next time you want to submit patches, you can avoid
resubmitting the same ones again:
cvs rtag -r HEAD patches-submitted-20010104 gcc
cvs rdiff -u -r patches-submitted-20001220 -r patches-submitted-20010104 gcc
I can also update the GCC sources when (haha) GCC 3.0 is released as
such:
tar zxvf gcc-3.0.tar.gz ; cd gcc-3.0
cvs import -m "Import of GCC 3.0" gcc GNU GCC_3_0
Then 'cvs checkout -j' can be used to merge any conflicts.
Is this correct?
Yes, but again, I tend to be paranoid and tag the thing up the wazoo:
cd my-gcc-sandbox
cvs update -A
# Tag the state of the world before you began the merge
cvs tag GCC_2_95_2_preupdate
# Deal manually with files that have moved/disappeared
# from the distribution between GCC 2.95.2 and 3.0. This
# may no longer be necessary; I haven't done much
# vendor-branch work since several CVS versions ago.
# Do the import
cvs import -m "Import of GCC 3.0" gcc GNU GCC_3_0
# Merge
cvs update -j GCC_2_95_2 -j GCC_3_0
# Resolve conflicts
# Optionally: commit and tag
cvs commit
cvs tag GCC_3_0_merged_preliminary
# Do some testing; fix any bugs you find that were
# introduced by the merge
# Decide that the merge is complete
cvs tag GCC_3_0_merged
Good luck.
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
Nobody ever got fired for buying Microsoft -- but they could get
fired for relying on Microsoft.
- Chris Garrigues
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merging Question
On Fri, Dec 22, 2000 at 10:13:08AM -0600, Alexander Kamilewicz wrote: However, the crux of my problem was that whenever I've been importing their new changes into a module, I _never_ get a conflict message. This is important, because in most cases I _know_ a file has changed (usually index.htm). No single change can result in a conflict. In your example, the distribution has changed, but you've made no local changes. Similarly, if you had made a local change, but that particular file was the same in the release-1 and release-2 distributions, there wouldn't be a conflict. A conflict only occurs when the distribution and your local copy have *both* changed. Thus, I embarked on the following simple exercise to prove myself right or wrong: [Previous steps omitted, for now...] 7. It imports fine with no conflicts. And so it should, because there are no conflicts. Thus, this behaviour is also correct: 10. I get "page1" with "second time" and "first time" is nowhere to be seen. To create a conflict, modify this test procedure as follows: 1. I create a directory called "acktest" with one file called "page1" that has one line that says "first time". No quotes in any of this, of course. 2. I import this into CVS as such: $cvs import acktest vendor release1 (NB: You have the right idea for the third argument, but the second should be the same for all import's; hence no need for a number. I've changed it to from "vendor1" to "vendor".) 3. It imports fine. 3.1 Check out a sandbox: cvs co -d acktest-sandbox acktest (NB: I call the sandbox "acktest-sandbox" here only to avoid collisions with the "acktest" directory, which you use for the third-party distributions. In practice, I'd call the sandbox "acktest" and put the distribution directories elsewhere -- they're transient anyway. Either way, I'd *certainly* avoid using the same directory for both purposes, with all the resulting deleting/recreating that you described.) 3.2 Make a local change, and commit it: cd acktest-sandbox vi page1# Make it say "first time, revised" cvs commit -m 'A local change to version "first time"' 3.3 Tag the state of the world before doing the next import: cvs tag release1-preupdate (I talked recently about how to do a "paranoid" import/merge; now I get to talk about why :-) I'll do that in a minute; for now, just humour me and make this tag.) 4. I rm -rf acktest. 5. I repeat step #1 with the one change that the one and only line now says "second time". 6. I import this into CVS as such: $cvs import acktest vendor release2 (NB: "vendor2" changed to "vendor", as in step 2) 7-b It imports, but says there's a conflict. 7.1 Merge the changes: cd acktest-sandbox cvs update -jrelease1 -jrelease2 7.2 Resolve the conflict: cd acktest-sandbox vi page1# We'll change it to "second time, plus first-time revisions" cvs commit -m 'Merge "first-time" revisions into "second-time" distribution' 7.3 Tag the results: cvs tag release2-merged (NB: This is also part of the "paranoid merge". It doesn't come into play in this message, and is shown only for completeness.) 8. I rm -rf acktest 9. I $cvs checkout acktest (NB: There's no real need to do this in practice, since you still have acktest-sandbox. But for the sake of argument, suppose you do it anyway.) 10-b Now you get "second time, plus first-time revisions" [...] there appears to be a) no version history and b) no way of "rolling back" when it turns out that their new changes aren't up to snuff. a) To convince yourself that there *is* version history, type: cd acktest-sandbox cvs log | more b) To roll back to the first import, as received from the other group, do: cd acktest-sandbox cvs update -r release1 But that loses your local patches to release1. What you probably wanted was: cvs update -r release1-preupdate# Roll back to release1, plus local patches This is why we did step 3.3. gripe This message is intended only for the use of the addressee(s) named herein. [7 more lines deleted] Do the lawyers who dream this crap up ever subscribe to mailing lists? (Alexander, I know this isn't your doing; my gripe isn't directed at you personally.) /gripe -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Proposal to fix CVS binary file implementation
On Thu, Dec 28, 2000 at 03:22:36PM -0600, David H. Thornley wrote: It could be worthwhile expanding the RCS format to do some better handling of binary files. It would be possible to improve the handling of binary files while keeping most of the code base. The extension to the RCS format (ie. the data-storage layer) should be a general one. It should provide for storing an arbitrary set of named attributes (ie. key/value pairs) per revision. There should also be a global set, whose attributes apply to all revisions (as the keyword-expansion setting currently does). Then the upper layers (ie. CVS proper) can define attributes to suit its purposes, eg: - binary/text flag - MIME type - keyword-expansion preferences (Whether these specific attributes should be per-revision or global is open to debate -- indeed, the debate is currently happening -- but in either case, under my proposal the decision does not affect the RCS layer.) More things that fall out of this: - One can imagine adding a per-revision attribute that says where in the sandbox this ,v file lives. Poof -- the revision-controlled mapping that Paul Sander (I think) was talking about. (There'd still be a need to map the other way, from sandbox name to ,v file -- but maybe the CVS/Entries file could do that). - One could add attributes for things like file permissions and the like -- anything that should be revision-controlled, but currently isn't. - Another attribute could be the filesystem object type (so named because "file type" is ambiguous; it can also refer to MIME type). More attributes to contain symlink values, device numbers, etc. - Expansion of arbitrary keywords (subject to keyword-expansion settings of course): if there's a "Foo" attribute, and the file contains a "$Foo$" keyword, expand it. (Needs an interface for setting them; to prevent people from using this to break CVS's own attributes, perhaps prepend "USER_" to all attributes set via the UI.) Any number of worthwhile proposals have foundered on the RCS-compatibility problem. So if it has to break, break it *once* -- in a general-enough way that the RCS layer need never change again. Looking at rcsfile(5), I find that provision has already been made for adding new metadata, both per-revision and globally -- the "newphrase" construction in the grammar. So perhaps the format doesn't have to break after all; what I'm suggesting is already basically there. Rather than adding an attribute mechanism, CVS could just define "newphrase"s where necessary, since, as David Thornley points out, CVS has internalized its RCS access, and is thus no longer dependent on the RCS code itself. (I just checked; RCS 5.7 can handle files with custom metadata, but it prints a warning. So even if CVS does extend the format in this way, that won't prevent people from using RCS to get at the data in an emergency.) If CVS opts for adding "newphrase"s, enhancing binary-file handling is a matter of defining one or more of them to contain the necessary metadata, and having CVS *ignore* the current keyword-expansion flag for any ,v file which contains the new-style metadata (for compatibility, the old flag should be honoured for files without new-style metadata). -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Performance
On Thu, Jan 04, 2001 at 04:51:23PM -0600, Cheryl Tipple wrote: It appears we have a performance problem within our CVS system. [CPU, network bandwidth, filesystem access path, RAM, swap are all far from saturated] Can anyone tell me if there are any [...] tests I can run to trace this problem? We are also going to try a network sniffer from our end to identify where the data is moving. How about physical disk I/O? You don't say which operations are causing you trouble, but update and commit both do a lot more disk I/O than one would naively expect -- they do locking by creating temporary directories (because mkdir() is atomic, I presume): 1. create a lock directory in each repository directory to be operated on, recursively all the way down 2. do the operation 3. delete all the lock directories Note that: - This is three recursive passes over the affected subtree, NOT a single pass in which all three operations are done on each directory as it is visited - The per-directory progress messages are all printed during step 2; steps 1 and 3 are silent. To find out how much of the slowness is network-related, remove the network from the equation: try doing the same operations locally (ie. non-client/server) on the server machine. To do this, set CVSROOT (or the value of the prefix -d option) to the unadorned absolute pathname of the repository, ie. with no access method specified. (Even if you don't want to give accounts to the developers, the admin can do a checkout or two for testing -- or even commits, on a scratch copy of the repository.) Good luck. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Importing vendor update without 1.1.1 branch
On Fri, Jan 05, 2001 at 01:48:32AM +, Kenn Humborg wrote: Starting with an empty CVS tree, we did cvs import -b 2.2.14 module vendor vendor-2-2 [...] We continued development, adding files and modifying a few vendor files. Now I'm trying to import an updated vendor tree [...]: cvs import module vendor vendor-2-4 New files in vendor-2-4 that were not in vendor-2-2 were added at version 1.1.1.1 and updated files were not added because branch 1.1.1 cannot be found. Oops! It tried to create a 1.1.1 vendor branch. I've scrambled enough repositories that I've come to think of importing as a dangerous operation -- dangerous enough to be worth backing up the repository first. (Not that I'm scrupulous about actually doing this, alas; there've been times I didn't bother, and regretted my laziness.) Since this is the state you're in now... So I rig up a script to get the names of these new files and use cvs admin -o 1.1.1: to clear everything out of this 1.1.1 branch. I'd have just deleted the ,v files. For these particular files, the only revision being lost is the one you're about to replace with the next attempt at importing. (Other files have revision history that you don't want to lose, of course, but those files don't need to be cleaned up.) Of course, I should have specified that the vendor branch is 2.2.14. So I tried again: cvs import -b 2.2.14 module vendor vendor-2-4 This time, updated files are imported OK at version 2.2.14.2, but new files are not added: cvs server: /cvsroot/proj/module/file,v: can't find branch point 2.2 cvs server: ERROR: Check-in of /cvsroot/proj/module/file,v failed Is this because 2.2.14 appeared "out of nowhere"? Not likely; after all, the same command worked on the vendor-2-2 import, when 2.2.14 was coming equally "out of nowhere". I rather suspect that this error is because of one or more of the following: - the files still have a "vendor" tag referring to the 1.1.1 branch, which conflicts with the new import command's request to assign that tag to branch 2.2.14 - deleting the 1.1.1.1 revisions left the ,v files in an inconsistent state (the "vendor-2-4" release tag still exists, even though the revision it refers to has vanished) - the files now have no revisions at all -- you deleted the only one there was This is why deleting the offending files is the better choice. Is there any hope for this tree? Would I be better off re-creating it from scratch (and living with the loss of history info)? Depends partly on what's happened since, I suppose. Have people continued doing commits? If they have, you'll want to check, before deleting those bad ,v files, that nobody's committed trunk revisions to them. Are there tools that can extract all the diffs and comments at each commit and "replay" them into a new tree to rebuild the history? Not that I know of. There sure have been times I've wanted one... -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Importing vendor update without 1.1.1 branch
On Sat, Jan 06, 2001 at 12:01:49AM +, Kenn Humborg wrote: On Fri, Jan 05, 2001 at 04:12:23PM -0500, Eric Siegerman wrote: I've scrambled enough repositories that I've come to think of importing as a dangerous operation Unfortunately, I was still under the impression that pretty much anything in a version control system should be undoable... Nice way to be enlightened :-) 1. Well, it is. Just not easily. 2. Anything you do to your sandbox is pretty easily recoverable. Some of the things you might do to your repository are a different story. 3. Welcome to CVS. Consider this a wart. I'd have just deleted the ,v files. It's hosted at SourceForge so I don't have access to the ,v files. Bleah :-( Of course, I should have specified that the vendor branch is 2.2.14. So I tried again: cvs import -b 2.2.14 module vendor vendor-2-4 This time, updated files are imported OK at version 2.2.14.2, but new files are not added: cvs server: /cvsroot/proj/module/file,v: can't find branch point 2.2 cvs server: ERROR: Check-in of /cvsroot/proj/module/file,v failed Is this because 2.2.14 appeared "out of nowhere"? Not likely; after all, the same command worked on the vendor-2-2 import, when 2.2.14 was coming equally "out of nowhere". I rather suspect that this error is because of one or more of the following: - the files still have a "vendor" tag referring to the 1.1.1 branch, which conflicts with the new import command's request to assign that tag to branch 2.2.14 But before the first import, the "vendor" tag referred to 2.2.14. So shouldn't that have failed the same way? Nope. CVS has no *global* idea of what a given tag means; each file has its own idea (tags and their values are stored separately in each ",v" file, not in some global database). So every file that existed in the vendor-2-2 import has: Tag Value Where it came from -- -- vendor 2.2.14 (b) import of 2.2 vendor-2-2 2.2.14.1 (r)import of 2.2 vendor-2-4 2.2.14.2 (r)second import of 2.4 But every file that didn't exist in 2.2 has: vendor 1.1.1 (b) first import of 2.4 vendor-2-4 1.1.1.1 (r) first import of 2.4 Those tags remain in the ,v file even if you delete revision 1.1.1.1 out from under them; you have to explicitly remove the tags. Do a "cvs log" of a file in each state, and you'll see what I mean. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Help attic - dead revisions
On Thu, Jan 11, 2001 at 09:10:19AM -0500, Derek R. Price wrote: luis Gonzalez wrote: Hi all: Please, how recover dead revision (attic). [...] an 'up -j -j' (see the manual on backing out changes) might work, but I don't remember if you can specify a single file to update when it's not present locally. This does indeed work. (As it happens, I was doing this a couple of days ago, using CVS 1.10.8.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs checkout merging with non-cvs source
On Wed, Jan 17, 2001 at 12:17:30PM -0800, James Shannon wrote: My group develops add-ons and custom solutions to a set of pre-developed sourcecode and I'm wondering if there is an easy way to checkout our custom solutions from CVS and merge them with the pre-developed source tree. [...] The idea is to have a CVS repository with only the new/modified files: This is exactly what the vendor branch is for! Let CVS manage the whole thing, including the pre-developed source. When you get a new distribution of the latter, you'll be glad you did! In the following, I assume you have a directory with the latest and greatest (non-cvsified) source, ie. the pre-developed source plus all your changes to date; I call this current. - make sure current doesn't contain any "CVS" directories (eg. left over from any previous attempts to CVSify it) - "cvs import" a vanilla copy of the pre-developed source distribution -- this MUST be a vanilla copy, without any of your local changes - "cvs co" the same (the resulting working directory is hereafter referred to as sandbox) - get a list of the files you've deleted from the distribution: % cd sandbox; find . -print | sort /tmp/vanilla % cd current; find . -print | sort /tmp/current % comm -23 vanilla current /tmp/deleted-files - recursively copy current (new files, modified files, unmodified files -- the whole works) OVER TOP OF your new sandbox; this will result in the sandbox containing your latest and greatest source, but with its CVS admin info pertaining to the vanilla distribution (not quite -- any files you've locally deleted will still be present; we'll deal with this momentarily) - Now "cd sandbox; cvs -nq update" will give you a complete list of the files you've added (flagged by "?") and changed (flagged by "M") -- but NOT the ones you've deleted, which is why you had to make a list of those before overlaying the two directories - "cvs add" any of the "?"-flagged files that should be CVS-tracked (exclude any cruft that's made it into current -- temporary files that people forgot to delete, etc.) - "cvs remove -f" the files you've deleted from the distribution, ie. the ones in the list you made above (though of course you'll want to verify that none of them were deleted by accident in the distant past :-) - "cvs commit" when we want to bring a pre-developed source tree to the modified state, we'd move to the root, issue checkout, and CVS would recurse through and add the two new files(newfile.pm and new-shared-file.pm) and update the two modified files(catalog.pm and Shared.pm). All other files it would leave alone. It would also add the necessary CVS directories so that we could do add's and commit's when need be. You'll end up with functionally this result, though by a different path than you'd imagined. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: listing symbolic links recursively, with dir listing
On Thu, Jan 18, 2001 at 05:42:52PM -0600, Chris Garrigues wrote:
From: David Glick [EMAIL PROTECTED]
Date: Thu, 18 Jan 2001 15:36:52 -0800 (PST)
Or you might try:
find . -type l -exec ls -l {} \;
Or (depending on your version of find):
find . -type l -ls
This:
find . -type l -print | xargs ls -l
might be faster, since it doesn't require a fork/exec for each
symlink (to be honest, I don't actually know how "find -ls" is
implemented; there may not be any improvement if, like xargs,
it batches them up).
This is a modification of my standard trick for getting an ls -l
with directories:
find . -print | xargs ls -ld
(The -d is crucial! Why is left as an exercise for the reader :-)
(When I taught an Intro to Unix course, I recommended that my students re-read
the find man page every few months. Every time I re-read it, I find something
I didn't know before.)
Quite possibly because it wasn't there before, or on the system
whose man page you were reading last time, etc. The core
functionality is pretty standard, but people (especially GNU)
extend it in all sorts of weird and wonderful ways...
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
Interviewer: You've been looking at the stars all your life:
Is there anything in astrology?
Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius,
so I'm naturally skeptical.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Spaces added ... and line endings in general
On Tue, Jan 23, 2001 at 06:40:19PM -0500, Laine Stump wrote:
Strikes me this might actualy make the CVS code simpler :-) ... instead
of converting to local conventions (thus needing too know what they
are) you would simply pass the cannonical file through a filter which
'localised' it as requested.
Right now CVS is relying on the C library file functions (fopen,
fputs, etc) to do the "filtering".
Yup; the CVS code is already as simple as it could possibly be:
open the working file with or without a "b" in the fopen() mode
string, and let stdio handle it from there.
[...] the only tool I
use that doesn't accept/deal with multiple line-end conventions is _CVS
itself_.
Your other tools deal with two line-end conventions, maybe three
(ie. Mac), if you're really lucky. It doesn't deal with *all*
relevent conventions.
CVS does, by definition (where the definition of "relevent" is
"CVS has been ported to it"). Automatically (see above). As
long as you don't try to fool it.
How should a *single* CVS executable "accept/deal with" all of
the following, which it *must* do if it's to defend itself
against the kinds of abuse you want to throw at it?
- Unix format: LF
- DOS format: CRLF
- Mac format: CR
- Files in which some lines use one of the above conventions,
and some use another (because you edited a DOS-format file in
vi on a Unix box, and didn't religiously type the ^v^m's)
- Unix-format files that contain CRs as actual formatting
characters -- perhaps even at the ends of lines, for doing
overstriking, so looking specifically for CRLF is unsafe
- Record-oriented formats which use length words and have no
terminator at all. This is old mainframe stuff -- dying, but
alas not dead yet. (For an example, see below.)
But it would need to be set in variety of ways:
setting on file,
overridden by .rc file,
overridden by environment,
overridden by cmd options
YES This is exactly what I'd like to see! (naysayers be damned! ;-)
Perhaps I'm being obtuse, but how does this help with the
following use case:
The only problem is when you do the checkout on platform X,
then work with that work directory on platform Y.
Semi-aside: here's an example of a record-oriented format, for
those who've never been, ahem, lucky enough to work on a system
that uses one. This is (as nearly as I can recall; it's been a
*long* time), the text-file format used by VMS. Each text line
consists of a "short" containing the record length, in binary,
followed by that many bytes of ASCII, padded to a word boundary.
Here's what my favourite Ogden Nash poem would look like in the
format I've described (which may or may not be exactly VMS's).
Notice the blank line between heading and body:
0008546865204c616d61000d6279204f
. .T he L am a. .b y O
6764656e204e61736800001a4120
g de n Na sh .. .. .A
6f6e652d4c206c616d61206865277320
o ne -L l am a he 's
6120707269657374001a412074776f2d
a p ri es t. .A t wo -
4c206c6c616d61206865277320612062
L l la ma h e' s a b
65617374001d416e64204920776f756c
e as t. .A nd I w ou l
642062657420612073696c6b2070616a
d b et a s il k pa j
616d6100001e54686572652069736e27
a ma .. .T he re i sn '
7420616e792074687265652d4c206c6c
t a ny t hr ee -L l l
6c616d61
l am a
Here's the cleartext:
The Lama
by Ogden Nash
A one-L lama he's a priest
A two-L llama he's a beast
And I would bet a silk pajama
There isn't any three-L lllama
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
Interviewer: You've been looking at the stars all your life:
Is there anything in astrology?
Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius,
so I'm naturally skeptical.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [To CVS-Dev] CVS Directory Order and sanity.sh
On Thu, Jan 25, 2001 at 05:23:37PM -0500, Larry Jones wrote:
2) It seems that quite often the order that files are processed is different on
MVS. For example, in basicb-7, the output that is expected is:
'T Emptydir/sfile1
T sdir2/sfile2'
but on MVS it's:
'T sdir2/sfile2
T Emptydir/sfile1'
I am assuming that the change is due to a different collating sequence between
ASCII and EBCDIC. My question is, shouldn't LC_COLLATE=C fix this? I looked in
the opendir/readdir function descriptions on several different UNIX (UNII?) and
LINUX docs and none mention the order that these files/directories should be
listed, nor use of LC_COLLATE.
In general, readdir() returns entries in whatever order they are
physically stored in the directory, it does no sorting of any kind.
Correct.
(In the case of basicb-7, for example, I think the
subdirectories should be processed in the order they occur in
CVS/Entries, which should be the order they were added in.)
Nope; CVS does them in alphabetical order (as it seems to do just
about everything except "import"). Tested by creating and "cvs
add"ing subdirectories in non-alphabetical order, hand-editing
CVS/Entries into a different non-alphabetical order, then doing
"cvs tag foo".
But CVS doesn't seem to do locale-based sorting. It uses
strcmp(), which just does a byte-for-byte numeric comparison.
This would explain the reported output; in EBCDIC, lower-case
letters do indeed sort before caps ('a' is 0x81; 'A' is 0xC1). A
quick grep for "sort" in the CVS 1.11 sources turns up at least
three functions that need changing:
history.c:sort_order
modules.c:sort_order
hash.c:fsortcmp
Solaris provides strcoll() and strxfrm() to do locale-based
string comparisons, but I have no idea how standard they are.
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
Interviewer: You've been looking at the stars all your life:
Is there anything in astrology?
Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius,
so I'm naturally skeptical.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 'cvs update' skipping directories
On Tue, Jan 30, 2001 at 03:34:16PM -0500, Peter Schuller wrote: Basically, if I do a check-out I get everything. But if someome else then adds a directory I sometimes (but not always) won't get a copy of that directory when doing "cvs update". It's just ignored completely This is the expected behaviour. "cvs update" gives you new files in directories you already have, but does NOT give you newly created directories. To get the latter, type "cvs update -d". One possible explanation for the "but not always" part: perhaps some people (but not everyone) has "-d" in their .cvsrc's. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Easiest way to move a branch to the trunk
On Fri, Feb 02, 2001 at 05:07:31AM -0800, Brian J. Murrell wrote: I have a project/repository which has a main branch (trunk) for stable, released versions and a development branch. The development branch was branched off of the main branch a while ago for development and has going along gangbusters. Now it is time to release. What is the easiest way to move the develoment branch onto the main branch so that what is on the main branch is completely replaced by the development branch. I realize of course I could use "cvs update -j" to move it all over but that is going to create a boatload of conflicts. I can deal with conflicts easily (and tediously) enough but I wonder why I should need to bother. It seems that I should be able to simply replace the contents of the main branch with the development branch in an easier way, no? All suggestions welcome, thanx. Here are some instructions I recently posted for someone else, lightly edited to reflect your situation, which is somewhat different from theirs: - Create a directory containing the latest development source, WITHOUT any CVS subdirectories (use "cvs export", or manually delete the CVS subdirectories from a preexisting sandbox). I'll call this dev. - Create another sandbox on the trunk (ie. the stable version), eg. using "cvs co" with no -r or -D options, or "cvs update -A". This sandbox is hereafter referred to as stable. - Get a list of the stable files you've deleted in development: % cd stable; find . -print | sort /tmp/stable % cd dev; find . -print | sort /tmp/dev % comm -23 stable dev /tmp/deleted-files - Recursively copy dev (new files, modified files, unmodified files -- the whole works) OVER TOP OF your stable sandbox; this will result in stable containing your development source, but with its CVS admin info pertaining to the stable version (not quite -- any files you've deleted in development will still be present; we'll deal with this momentarily) - Now, "cd stable; cvs -nq update" will give you a complete list of the files you've added (flagged by "?") and changed (flagged by "M") -- but NOT the ones you've deleted, which is why you had to make a list of those before overlaying the two directories - "cvs add" any of the "?"-flagged files that should be CVS-tracked (exclude any cruft that's made it into dev -- temporary files that people forgot to delete, etc.) - "cvs remove -f" the files you've deleted in development, ie. the ones in the list you made above (though of course you'll want to verify that none of them were deleted by accident in the distant past :-) - "cvs commit" -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
wincvs.org - cvsgui.org
Someone mentioned recently that www.wincvs.org seemed to have gone away. Turns out it's been renamed to www.cvsgui.org. To quote from the news item on the site: As the objective of the CvsGui project is resolutely to cross the platforms barriers, the new name makes more sense for the users of MacCvs and gCvs. As it happens, the old name is back now -- but only as a redirect to the new one, so it might not stay around for long. (Gotta like mindit for telling me when wincvs.org reappeared!) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Force CVS to using root to commit files (one way or another)
On Thu, Feb 08, 2001 at 09:57:57AM -0500, Todd Denniston wrote: Matthew J Fletcher wrote: - Due to the requirements of our work we need to be operating as root, (this is set in stone, honist), [...] the only time you NEED to be root is to "make install [...]", assuming you know how to use file permissions. Technically true. They may have some broken development process mandated by some pointy-haired boss, though. Beyond the scope of this list... eg,. #!/bin/bash su matt tkcvs -dir /usr/src/cvssources exit but it dont work,.. any ideas ? No, it wouldn't. The "su" command starts up a shell that reads from standard input, which is your terminal, not the script. When you quit that shell, the script continues (with the "tkcvs" command) in the old context, ie. as root. Try this: #!/bin/bash su - matt -c "tkcvs -dir /usr/src/cvssources" exit Not all variants of "su" take a -c option; depends which flavour of Unix you're using. If yours doesn't, try this version, which supplies the command you want to run as standard input to the "su" command, and thus to the subshell that it spawns: #!/bin/bash echo "tkcvs -dir /usr/src/cvssources; exit" | su matt (You almost certainly don't need the "; exit", since the subshell should exit on its own when it sees end-of-file. I added it for completeness, in case bash has been told to ignore end-of-file.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: version control with shared workplace
Here's what I wrote a couple of months ago (with a few small revisions) in response to a similar question. I guess it's a FAQ (hint to that person who's compiling one). On Thu, Feb 08, 2001 at 03:57:14PM +0100, kozma peter wrote: I would like to set up a version control system for a website with lot of server side scripting. Because of the server side scripts it is inevitable that the developers use a shared working place, namely the document root of the webserver (otherwise they cannot check the effects of their changes immediately). What we do is give everyone their own WWW server and JRun instance (JRun being a Java servlet server), both tied to their personal CVS sandbox (indeed, in our shop, the word "sandbox" has come to signify not just the CVS working directory, but that plus its associated server instances). Besides going along with the CVS paradigm for its own sake, this gets us the advantages which that paradigm was designed for in the first place: - concurrent editing - each developer can test their own work in isolation (since each has their own WWW server to test it on) We intend to set up separate integration sandboxes, and institute some procedures for using them, but that hasn't really happened yet -- too busy developing :-/ I wrote a Perl script to check out a new CVS working directory, create a new JRun instance, and tie them together; unfortunately, the configuration for Netscape's WWW server is weird enough that I didn't feel comfortable automating it, so that step is still done manually. With Apache, this part can be automated as well, as my colleague has done (note that it's better to give each user their own Apache instance, not just a virtual server; that way they can edit their Apache configuration, start and stop their server, etc., without breaking other peoples' environments). On the development machine, we divided the IP port space into 200-port blocks starting at 1; each sandbox is allocated one block of ports. A few of the ports are predefined (with the offsets being, hopefully, somewhat mnemonic): BASE+0 = JRun admin BASE+1 = Jrun JCP (ie. the servlet server) BASE+80 = HTTP server BASE+99 = Java RMI A couple of things my colleague did differently: - He assigned port blocks based on "your phone extension * 100" (he was using 100-port blocks) -- but this may not make sense in every situation. - He used BASE+0 for the HTTP server. This makes a lot of sense, and I plan to use it from now on -- of all those preassigned ports, this is the only one you tend to type a lot; the rest go into a config file or two and are then forgotten. The rest of the ports in the block are free for the developer to use however they like. This has the fringe benefit of offloading port administration from the sysadmin: if a programmer wants to run something that works over IP -- a network-aware Java debugger, a networked game, or whatever -- they don't have to bug the sysadmin for a free port number. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: version control with shared workplace
[I've cc'ed this back to info-cvs, since others may be interested] On Fri, Feb 09, 2001 at 05:31:20PM +0100, kozma peter wrote: isn't this setup [HTTP and JRun server per CVS sandbox] eating up the webserver's ram and cpu at lightspeed? CPU, no. Sure there are lots of processes, but they all spend (100 - epsilon) percent of their time idle. Memory, yeah, it tends to use up a bit. But that's what swap space is for :-) Remember, these aren't production servers; they're only being hit by one developer each, and sporadically at that. That said, the client I've just finished with is using the same scheme on their (very-high-traffic) production servers, and having no real problems. They just put *lots* of RAM on their machines (1 GB at least, maybe 2). I'm guessing (well, hoping) that they don't see significant paging, but I don't know for sure -- I wasn't paying much attention, since I was there to write code, not do sysadminning. having 5 or 10 servlet runners means having 5 or 10 jvms, right? Yup. Again, idle most of the time, so who cares? how many developers are using this server at the same time? and what kind of hadware is it running on? To be honest, I don't recall the details. The development server at said client was a Sun running Solaris Sparc, but I couldn't tell you much more than that, except that I think someone remarked that it was an old box. Probably 8-12 programmers developing and testing Java servlets, with each programmer: - using their own CVS sandbox and server instances, as I've already described - doing Java compiling - doing CVS commits, updates, etc. - some of us editing on the server too, and doing other Unix'y things (though many preferred to edit on their PCs) I spent all my time telnetted into that box (since I strongly prefer working on Unix over Windows), and rarely if ever felt that the machine was overloaded -- it *didn't* get noticeably faster when everyone else went home for the night. I guess the most telling thing is, I instituted CVS, and the server-per-sandbox thing, at this site. Of course there was initial grumbling (mostly about CVS per se -- the usual confusion about concurrent editing, lack of reserved checkouts, etc; none that I recall about system slowness or the like); but later, when I asked people what improvements they'd like to see in the development setup, I didn't get *any* complaints/suggestions -- except that the integration sandboxes/procedures that I alluded to in my post hadn't been done, ie. that we hadn't finished CVSifying the shop. Back at our own office, we have a PC server (P3/600, 512 MB RAM) running Linux, serving 4-5 developers. The box feels dramatically faster than the above Sun, and has half the users, so it's not too surprising that there haven't been any complaints. Caveat: you have to put a bit of effort into arranging that your code can run in multiple sandboxes. With the kind of command-line app that was standard when CVS was invented, there isn't a problem. But with WWW apps, things are a bit more tricky: - HTML should use relative links - Servlets can't hard-code directory paths (eg. where to find properties files), port numbers (for things like the port for the RMI registry), etc. Thus, you need to provide for properties that are local to each sandbox. At the same time, most of an application's properties aren't intrinsically sandbox-specific, so you want those shared between sandboxes (ie. cvs-controlled, like the source code). So you should ideally provide for both shared and local properties. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs and jbuilder
On Mon, Feb 12, 2001 at 01:12:08PM -0500, Larry Jones wrote: Konrad Hernblad writes: in cvs, i would like to store the c:\project\src directory as "project-src", but when i checkout "project-src", i would like the local directory name to be "src" (as it was originally), and not "project-src". Use the -d option of checkout or define a module that includes it. Or just go with the JBuilder flow, and import it as "project/src" in the first place. Granted, you don't want to CVSify the other JBuilder directories. But for some projects, you might create your own subdirectories that you do want under CVS control (properties files, documentation, test cases, static HTML -- just a few possibilities that come to mind). Not to mention the main JBuilder project file (*.prj or whatever it's called). When that need arises, it'll be nice to have the structure in place so you can just "cvs add" the directories in question. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Does Entries.Log ever contain files, or just directories ?
On Mon, Feb 12, 2001 at 02:33:08PM -0600, R Bresner wrote: So, is it safe to assume that the temporary Entries files [Entries.Log and such] operate only on the module level? I rather doubt it! Even if your observations are currently valid, who can predict how CVS's internals will change in a year or five? Given that the manual gives detailed instructions for interpreting Entries.Log, why second-guess them? lecture If something's not part of a documented interface, it should be considered subject to change without notice; depending on it is a recipe for grief. Not just for CVS; this applies pretty much across the board. (Of course, sometimes you have no choice -- but be aware of the risk.) /lecture -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checking out src code from dev repo to release repo.
On Tue, Feb 13, 2001 at 08:42:14AM +1000, Peter Disiot wrote: I'm doing a project where we check into the repo, source code that is reviewed, and tested. We require a sandbox type repository, where we can put our stubs etc. Do I understand correctly that you're trying to create one repository for "approved" sources, and one for not-yet-approved work in progress? (If not, my comments may not make much sense.) Essentially we have two repositories, one call dev/projectName and the other simply called projectName. How do I checkout code etc from the dev repo into the projectName repo. I've tried the -d on the co command but I get a "repo dev does not match repo projectName" error. No, CVS doesn't work that way. A sandbox can only be associated with one repository! CVS doesn't directly support what you're trying to do, but you could fake it with branches: - When a programmer starts on a task, they create a branch to be used exclusively for that task. - They happily commit on the task branch. (This doesn't affect people working on other tasks, since each task has its own branch.) - When they're ready to submit their work for review, they simply tell the reviewer the name of the task branch. - When the reviewer has approved the changes, they merge the task branch into the mainline. - That task branch is NOT used for any other work. If the reviewer asks for changes, of course, those will be made on the task branch in question; but once the task has been accepted and merged, its task branch should be retired permanently (though probably still kept in the repo for reference). - Someone just posted patches to implement per-branch permissions. You might consider using these, and making retired task branches read-only. Thus, the mainline (aka trunk) contains approved work, and the work in progress appears on many short-lived task branches. (There will likely also be other longer-lived branches, for post-release bug fixes and the like. The bug-fixing work might itself be done on task branches, but merged into the bugfix branch, instead of into the trunk.) This repo will rapidly become an incomprehensible mess, unless you write some wrapper scripts to: - ensure that things are done in a methodical way (enforce a naming scheme for branches, among other things) - keep track of which branches are "live" and which have been retired (since CVS can't do that) - provide a way for people to list only the active branches, and/or to list all the branches with their statuses (after a while, the great majority of branches will be retired ones, and visually weeding through the list CVS provides will be annoying and error-prone) - update the per-branch permissions, if you opt to go that route Possible alternative source-control systems (which I haven't used, but which contain features that you might find helpful): - Aegis, which is claimed to let you enforce process (eg. code must have regression tests, and pass them, before you can commit it). - ODE, which already distinguishes between the operations "commit" and "publish" (I'm probably misremembering the terminology). "Commit" creates new revisions, but they're only visible to the committer. "Publish" is what makes the work visible to the rest of the team. So you can do a bunch of commits, to keep track of your own work, without worrying about breaking things for others; and only publish your work when it's ready for public consumption. (I can't remember whether you can "publish" to the reviewer but not to other developers; for you, that's a key issue.) CVS, of course, doesn't make this distinction -- a "cvs commit" does both things. My suggestion above is precisely an attempt to fake ODE's commit/publish distinction in CVS. I guess this is a two fold question in that maybe our process is wrong. Not your process; just your attempt to fit CVS to it :-) Though extreme-programming folks would probably disagree... -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs add --new
On Thu, Feb 15, 2001 at 01:43:32PM -0600, [EMAIL PROTECTED] wrote: ["cvs add --new" wanted because "cvs import" doesn't insert metadata] It seems that what is being asked for is a CVS command to convert a regular directory into a cvs workspace directory so that it isn't necessary to do an initial checkout. But in virtually every situation (there may be an occasional exception), everyone that is working on a project needs their own workspace directory. So, everybody for the most part has to do a checkout anyway. If it's a one-person project (including local mods to downloaded open-source code), the savings would be rather greater -- nearly 50% of the effort of CVSifying a package. I also resented at first that I had to go through this extra step. But I came to appreciate it: - It's comforting to know that "import" is a read-only operation as far as the original directory is concerned; you don't have to back it up first - It's possible to diff the original directory with the new sandbox to make sure nothing went wrong with the import The one thing that would be useful, IMO, would be a way to create a top-level directory in the repository. The trick of doing a "-l" checkout of the root directory is a kludge. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: One working copy part of two repositories?
On Mon, Feb 19, 2001 at 05:50:10PM +0100, Stefan Bellon wrote: At first my questions seems to be strange and sounds like nonsense. That's why I will elaborate on the task I want it to do: Imagine you're porting a big program from one platform to another. The main tree of the program is already held in CVS. So I check out a working copy from this main repository. During the porting I want to have full control over my changes in a local repository so that I can step backwards if something breaks, etc. So I import it into my local repository. But now I have a problem w.r.t. the CVS directories in the working copy. Is there any way of synchronising such a development? Please don't suggest to use the main repository as this is no option. I'll have to use a local one, but later on I want to check in the changes into the main repository -- when they're stable. You should create a branch in the main repository to hold your porting work. Ideally, you could do the work directly on this branch, and only merge once the sources were stable. I'm not sure why you consider this not to be an option, since it won't impact on others until it until you've finished your port, and are ready to merge the results back into the mainline -- that's what branches are for, after all. But if there are other reasons you can't use the main repository (eg. the machine which hosts it isn't visible to the one where you'll be doing your work), do the following. You'll still create a branch in the main repository at the beginning of the port; but the branch will sit idle until final-merge time. In the following, upper-case names are my symbolic names for the various things you'll be working with. For convenience, =FOO= marks the name's definition. I'm assuming that the port is to be done on a machine not visible from the CVS server, and have thus included non-CVS copying steps. Steps flagged with "*" are done on the CVS server, or a client CVS-visible from it. Those flagged with "-" are done on the porting machine. Those flagged with "?" are the copying steps between the two machines; if my assumption is false, these steps are unneeded. Initial preparation: * In the main repository =REPOS-MAIN=, create a branch =PORT-BRANCH= for your porting work * Check out a new sandbox =SB-MAIN= on PORT-BRANCH ? Copy SB-MAIN to the machine where you'll do the porting work (use tar and ftp, floppy disks, or whatever) - Make a copy of SB-MAIN; call it =EXPORT-SOURCES= - Delete all the CVS metadata from EXPORT-SOURCES: cd EXPORT-SOURCES find . -type d -name CVS -print | xargs rm -rf (Don't take the obvious shortcut of just using "cvs export"; later, you'll need the unmodified SB-MAIN) - Import EXPORT-SOURCES into your own private repository, =REPOS-WORK= - Check out a sandbox from REPOS-WORK; call it =SB-WORK= - EXPORT-SOURCES is now junk; you can safely delete it Now do your port in SB-WORK, committing to REPOS-WORK at will. When you're ready to merge back into the main repository: - Make backups of both SB-MAIN and SB-WORK! I can't stress this enough -- in case something goes wrong (which it may well do), you'll *need* virgin copies with which to try again. - From SB-WORK, delete all the CVS metadata (see above "find" pipeline) - From SB-MAIN, delete everything which is NOT CVS metadata. Perhaps something like this will do, but be careful: cd SB-MAIN find . -type f -print | grep -v '/CVS/' | xargs rm - Recursively copy (what's left of) SB-WORK over top of (what's left of) SB-MAIN - Now, SB-MAIN contains your modified sources, but with CVS metadata appropriate to the original, unmodified sources on PORT-BRANCH in the main repository REPOS-MAIN, as of the beginning of your porting work ? Copy this merged SB-MAIN back to the machine on which it was originally checked out * In SB-MAIN, "cvs add" and "cvs rm" any files that need it * commit (recall that this is to PORT-BRANCH; your changes are still not visible to people working on the mainline) * Using REPOS-MAIN, do a vanilla merge from PORT-BRANCH to the trunk I haven't done all of this, but I've done a subset: working disconnected without bothering to create a REPOS-WORK, ie. with my working sources not CVS-controlled. This subset of the above recipe consisted of the steps flagged with "*" and "?"; on the remote machine, I just worked in the untarred SB-MAIN (complete with CVS metadata appropriate to REPOS-MAIN), then tarred it up again when done. But my disconnected sandbox was still given its own branch. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) _
Re: Terminated with fatal signal 11
On Tue, Feb 20, 2001 at 01:48:15PM -0500, Larry Jones wrote: =?iso-8859-1?Q?Szab=F3=20Tam=E1s?= writes: cvstest.txt: owner mismatch between 1.5 and working file cvstest.txt: group mismatch between 1.5 and working file Terminated with fatal signal 11 You're running with PreservePermissions enabled. The PreservePermissions code is so buggy that it has been disabled by default in recent releases of CVS; you should not use it. Which also suggests that you're not running a recent release. If not, consider upgrading to 1.11... -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: command help
On Wed, Feb 21, 2001 at 02:59:08PM -0500, ari gold wrote: is there a CVS command that will show me files that are in CVS, but that i've deleted locally? "cvs -nq update" -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Q: Export/Import for multiple platforms
On Tue, Feb 27, 2001 at 10:53:47AM -0600, Matthew Pressly wrote: Is using export and import a reliable way to maintain files across two platforms that have no physical network connection (only means of data transfer is via removeable media) For a slight variant, see my post of 20-Feb-2001, with the subject "One working copy part of two repositories?" When I import into A, will I always have to do a merge to get any changes onto the main branch? Yes. What if someone else committed changes at A while you were hacking away over at B? (If nobody did so, the merge will be trivial.) My variant saves you having to import (at the expense of some other commands), but doesn't save you having to merge -- that part you just can't get around. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Updating the default cvsignore list
On Wed, Feb 28, 2001 at 04:51:39PM -0500, Derek R. Price wrote: *.gz Gzip *.bz2Bzip2 These concern me: - It's a commonplace that generated files and temporary junk shouldn't be revision-controlled, but everything else should be. - To generalize the above: files should be revision-controlled (or not) based on their role, not on their form. (The fight over binary files only settled down when people stopped conflating "binary" with "generated", ie. stopped confusing the file's form (non-text) with what had once been -- but was no longer -- the exclusive function of non-text files (object code). - CVS should be conservative in what it *automatically* omits from revision control. If it accidentally checks in a secondary (ie. generated) file, no harm done; the user can just "cvs rm" the file and get on with life. If CVS accidentally fails to revision-control a primary file, perhaps-crucial history may be lost before the user discovers and rectifies the problem. - Thus, a pattern should only be added to the ignore list based on the role, not the form, of files it matches, and with great caution at that. - To ignore compressed files per se violates this; compression is orthogonal to whatever role a file (or at least, its uncompressed form) plays. By ignoring them, CVS in effect tries to second-guess the user (which has already been deemed a Bad Thing, eg. the decision not to try to guess for -kb purposes whether a file is text or binary). Leaving aside the ten I don't understand, all but one of the current ignore-list entries is either: - and administrative overhead file of some sort (. and .. -- admittedly a UNIX-centric opinion -- also CVS and CVS.adm) - a generated file, of a sort that should rarely be CVSified (*.o, .#*, etc.) - a common convention for user-created backup files, ie. junk (*.bak, *.old) - a convention for revision-control repositories (RCS, SCCS) -- these were once gold, but are junk from CVS's point of view; to preserve their value, you have to do more than just import them, eg. rcs-to-cvs. On these grounds, *,v should probably be added to the list. - some patterns fall into more than one of these categories; *.orig and *.rej are generated junk Ie. they all satisfy my criterion of ignoring based on role. The one exception, of course, is *.Z. It's probably there for historical reasons; if I recall, in the ancient past CVS didn't handle binary files correctly (there was no -kb), so it was positively dangerous to track them regardless of their role). But now that binary files are supported, I think *.Z should be *removed* from the list; to add other compression formats is going the wrong direction! *.flags Linux source These files may be generated in a limited context, but it's far from a common convention. Conservativeness argues against ignoring them by default. ID GNU id-utils database file Likewise. I have this in my ~/.cvsignore, but I doubt it should be in the default list, since it's only a generated file on those systems that happen to have id-utils installed, and even then, only in the sandboxes of those users who happen to use id-utils. Similarly, as a VIM user, I also have .*.swp and .sw? in my ~/.cvsignore, but I would NOT advocate putting those in the default list; the domain in which they're dependably ignorable is too restricted. *.libDOS/Windows library *.dllDOS/Windows dynamic load library *.sl HP-UX sharable library These are system-dependent (*.sl more than others :-). So are . and .. from the current list, as I mentioned; also *.so, and probably others. Perhaps some entries on the ignore list should be made explicitly system-dependent, so as not to ignore everywhere patterns that only match generated files on some machines. *.dviTeX output *.info* GNU info file Someone objected to *.info* on the grounds that they're often included in distributions. Same's true of *.dvi, so whichever way the *.info* decision goes, *.dvi should probably follow. To summarize: - it's ok to ignore generated files and junk; everything else should be tracked by default - it's NOT safe to try to intuit a file's role from its form (compressed, encrypted, etc.) - ignore *,v - don't ignore *.gz, *.bz2, *.flags, ID - ignore *.lib, *.dll, *.sl, but only on the appropriate systems; also consider which of the current entries should be made system-dependent - *.dvi should go the same way as *.info*, whichever way that is -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However,
Re: moving repo
On Thu, Mar 01, 2001 at 08:40:01AM +, Martin Tomes wrote: "Rob" == Rob Helmer [EMAIL PROTECTED] writes: Rob [...] I am wondering about people's experiences moving repositories I have a perl program which you can modify and use to switch peoples checked out code to use the new repository. We have moves ours several times without problems. If you want the program mail me. To avoid having to deal with this again next time, do the following: - wherever you physically put the repo on the new machine, make a symlink to it in a standard location (my own convention is /Repos) - make a DNS alias (ie. CNAME) for the CVS server machine (my convention is "cvs") -- you can also do this in /etc/hosts, of course, if that's how you run your network Tell people to check out their new sandbox using: cvs -d cvs.mydomain.com:/Repos co ... instead of using either the machine's real name or the repo's real pathname. Then, if you ever have to move the repo to a new server, or to a new (eg. larger) partition on the same server, you can do it transparently by changing the appropriate pointer(s). Of course you can invent your own conventions if mine aren't to your taste ... but once you do, stick to them! -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Standalone CVS pserver
On Thu, Mar 01, 2001 at 04:22:26PM -, Darren Young wrote: Now, what I would like to do is something like this: $HOME/bin/cvs --allow-root=$HOME/cvsroot -T$HOME/tmp -f pserver It seems to start fine, although if I touch my keyboard it stops. In a second shell session, netstat -na | grep 2401 doesn't show me listening() either.? It probably stopped as soon as you started it; you just aren't *told* about that until you touch the keyboard. To see what I mean, try this: - type "sleep 3 " - wait 10 seconds or so; nothing will happen, even though the sleep finished several seconds ago - hit Return; only now are you told about the sleep command being done This is a feature of the shell, to keep the "background-command finished" notification from being lost in the output from some other command. As for why it stopped in the first place, I'm afraid I can't help; I've never used pserver. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: pserver question
On Thu, Mar 01, 2001 at 11:38:16AM -0500, Derek R. Price wrote:
Peter Ajamian wrote:
There's a utility available
that I just finished work on this past week which will maintain the
passwd and readers files for you automatically (it works similar to the
regular Unix passwd program).
I was always fond of:
perl -e 'print crypt ("passwd", "st") . "\n"'
myself.
That's fine if you want to give all your CVS users write access
to the password file...
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: loginfo file
On Fri, Mar 02, 2001 at 08:39:57AM -, Rui Cordeiro wrote: Is there a way to represent a path in the loginfo file with spaces characters, something like: "^users/my home" You can approximate it with "^users/my.home". This will, of course, match a few more files than you want it to, but: - depending on the actual pattern, this may never happen in practice - your loginfo script could check for the false positives, and silently ignore them -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to get edit -c working
On Fri, Mar 02, 2001 at 10:54:59AM -0800, Chris Chambers wrote: The DB developers have fancy tools to allow them to edit, run, and debug their code directly in the (single, shared) database. But no tools to keep versions of the code. They need to keep using those fancy tools. But when one person is fancily editing the code directly in the DB, we want to have a portion of the development process inform others that they're not allowed to edit that piece of code. I had been thinking, export all the DB code as text, and use exclusive locking. If locking's the crucial part, and you're willing to dispense with versioning (which I wouldn't be, but your situation -- aka desperation level -- may be different), you could implement the lock as a table in the database that's being worked on. (You'll end up with a small bit of the schema that has nothing to do with the application itself, but it shouldn't be too intrusive -- a single table is all this should take.) Presumably the "fancy tools" are fancy enough to have user-definable triggers; so make them: - check and set the lock - do the editing/installing/testing - unlock -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge/diff
On Fri, Mar 02, 2001 at 03:52:03PM -0700, Derek Scherger wrote:
So I'm sitting here, in merge hell with one particular file that has had
lots of cosmetic (whitespace) changes since being branched,
Been there!
I'll assume the cosmetic changes were made on the branch; if they
were on the trunk, the following will be kinda backwards, but
should still give you the general idea...
Are the cosmetic changes mechanical in nature? Ie. could you,
without too much trouble, make *exactly* corresponding changes in
the trunk? This would be the case if the file was run through
"indent", for example. If so:
- On the trunk and in your sandbox, back out the merge work
you've done so far on this file (keep a backup of course);
it'll be better if you start fresh
- Get onto the trunk: "cvs update -A"
- Make cosmetic changes on the trunk corresponding to the ones
that were made on the branch
- Use (cvs) diff to check that you got it right, ie. keep at it
until "cvs diff -rbranch" shows no or few gratuitous changes
- Commit this version ON THE TRUNK (it should differ *only*
cosmetically from the version that was there before you
started)
- Try the merge again; it should go cleaner now
Alternatively, if the cosmetic changes were committed separately
from any substantive changes, you might be able to replace the
"make cosmetic changes" step above with something like:
cvs diff -rbranch-rev-before-cosmetic-changes \
-rbranch-rev-with-cosmetic-changes \
-u myfile.c |
patch myfile.c
This will get you into the same state as my first recipe.
If the cosmetic changes were committed separately, but the above
doesn't work, try:
- Revert and get onto the trunk, as above
- Merge all changes from the beginning of the branch (or
previous merge point) up to BUT NOT INCLUDING the cosmetic
changes. This should go easily:
cvs diff -rbranch-point \
-rbranch-rev-before-cosmetic-changes \
-u myfile.c |
patch myfile.c
- Merge all changes from just after the cosmetic changes up to
the present. This will have to be done by hand, but (especially
if the cosmetic changes were recent), the work will have been reduced:
cvs diff -rbranch-rev-after-cosmetic-changes \
-rbranch \
-u myfile.c
apply these diffs the hard way
- now make the cosmetic changes, mechanically or manually, or
decide they were a bonehead idea in the first place and just
abandon them...
Another possibility (which falls somewhere in the middle of the
above in terms of preferability): apply patches the other way --
merge this one file *from* trunk *to* branch. This will work if
there were only a few changes on the trunk; you'll still have to
apply these changes by hand, but there'll be fewer to deal with.
You don't necessarily have to commit the results of this to the
branch; you can commit it to the trunk by:
- make the changes
- mv myfile.c myfile.c-merged
- cvs update -A // will refetch the unmodified version
- mv myfile.c-merged myfile.c // replaces that with your modified one
- cvs commit
Advice for the future: If I'm making cosmetic changes to a file
-- especially big global ones -- I find that a bit of extra
effort at the time can save a *lot* of grief later. I make a
point of isolating such changes as a separate revision, and
being sure to say "no substantive changes" in the log message
(after, of course, verifying that no substantive changes crept in
while I wasn't looking :-). Doing so:
- makes merges like this easier, since I can play games like
the ones described above
- makes "cvs diff"'s easier; instead of
cvs diff -rold -rnew
which will print lots of useless stuff, I can go:
cvs diff -rold -rrev-before-cosmetic-changes
cvs diff -rrev-with-cosmetic-changes -rnew
to see only the changes that actually changed anything.
(The "no substantive changes" in the log message is what
assures me that the output of:
cvs diff -rrev-before-cosmetic-changes \
-rrev-with-cosmetic-changes
will be boring.)
Good luck!
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: update -jx -jy gives conflict on $Id$
On Thu, Mar 08, 2001 at 04:22:16PM -0800, Stephen Rasku wrote: Mike Castle wrote: On Thu, Mar 08, 2001 at 11:15:52AM -0800, Stephen Rasku wrote: Why is this [that -kk during merge is sticky] a problem? You can always do "cvs update -A" after you have checked in your changes to get rid of the sticky tag. Because it mucks up binary files? That shouldn't apply in this case since he was attempting a merge of, apparently, a .c file. If one's merging an entire tree, the -A you use to fix the text files will break the binary files for which it's not needed, but is perforce in effect anyway. Similarly, as someone else pointed out, it'll trash any sticky branch that's in effect. All of this points to the need for non-sticky variants of at least some normally-sticky options. What to call them, though? I'd suggest the easily-remembered rule that -X be a nonsticky version of -x (for all relevent values of x) ... but -D's being sticky gets in the way. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore and directories
On Mon, Mar 12, 2001 at 03:53:07PM -, [EMAIL PROTECTED] wrote: . \- Translator \- Binaries.Linux.i386 Translator is in the tree, but Binaries is created by the makefiles. There is a .cvsignore file in Translator which contains the line "Binaries.*". However, when I run cvs update I get this: cvs update: in directory Binaries.Linux.i386: cvs update: cannot open CVS/Entries for reading: No such file or directory Perhaps there's already a Translator/Binaries.Linux.i386 directory in the repository. If I recall, a file (or directory) being present in the repo trumps its being listed in .cvsignore. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Restoring vendor tag
On Tue, Mar 13, 2001 at 04:08:02PM -0800, Stephen Rasku wrote: Is there a way to reconstruct the vendor tag if it's deleted? Which tag? The one for the vendor branch itself? CVS doesn't want to do it, so you have to punt to RCS: cvs admin -nVENDOR:1.1.1 (where VENDOR is the name you want to use for the vendor-branch tag) The one for the latest vendor import? cvs tag -rVENDOR RELEASE (Since this isn't the above case, I assume the VENDOR tag still exists :-) For some previous vendor-branch import? You're SOL... -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: add directory heirarchy
On Wed, Mar 14, 2001 at 02:11:42PM -0500, Derek R. Price wrote:
$ find newdir -type f -exec cvs add {} \;
$ find newdir \( -type f -o -type d \) -exec cvs add {} \;
If you don't add the directories, you can't add the files...
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and binary files
On Thu, Mar 15, 2001 at 03:52:00PM -, [EMAIL PROTECTED] wrote: I still need to force cvs NOT to keep version history for some files. .cvsignore -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to avoid propogation of changes
On Thu, Mar 15, 2001 at 03:06:03PM -0600, [EMAIL PROTECTED] wrote: On Thu, Mar 15, 2001 at 01:22:40PM -0600, David H. Thornley wrote: [EMAIL PROTECTED] wrote: Here is the problem: What if we make a change that we don't want propogated downstream. [ie. merged from a one branch to the trunk] [...] we maintain_MERGED tags on our branches, so BRANCH_3 would have an associated BRANCH_3_MERGED tag. We have a Perl script that will merge from a branch to, say, head. It merges everything from BRANCH_3_MERGED to BRANCH_3, and then moves BRANCH_3_MERGED. This means that the way to avoid propagating a change is to move BRANCH_3_MERGED past it, and this is indeed what we do (I've got a Perl script for that, too, for consistency, and it's pretty short.) This would require us to merge all of our files individually, whereas we merge the entire branch in a single command, I'll refer to such changes (ie. that aren't supposed to be propagated) as "temporary changes". Procedure 1: This is easiest, *if* you can get away with it. If you're about to check in a change that you know is a temporary one, and if the people working on the mainline are willing to let you do a merge, you can: - Merge the branch, and update its _MERGED tag - Check in the temporary change - Move the _MERGED tag past the temporary change Procedure 2a: If you know the change is temporary, but you can't do a merge at the moment, then tag the change, to make Procedure 2b easier when the time comes: - Make sure your sandbox on the branch is up to date - Tag the branch with a release tag. I'll call the tag PRE_CHANGE, but of course your tag name should be a lot more explicit. - Commit the temporary change. - Tag the branch again (I'll call the tag POST_CHANGE). Procedure 2b: This happens when you're ready to do the merge. At this point, your sandbox on the branch contains the temporary change, as well as other changes that *should* be merged. Do this: - Make sure your sandbox on the branch is up to date. - Revert the temporary change. Assuming you tagged the change as in Procedure 2, this looks like: cvs update -jPOST_CHANGE -jPRE_CHANGE Note the ordering of the -j options. This says to *undo* the change. - Resolve conflicts; test; commit on the branch. At this point, the branch contains the permanent changes, but not the temporary one. - Merge the branch, and update its _MERGED tag. - If you still want the temporary change *on the branch*, do this (which is essentially Procedure 1): - Reapply the temporary change: cvs update -jPRE_CHANGE -jPOST_CHANGE (Yup, the -j's are the other way around this time) - Commit it - Move the _MERGED tag past it Procedure 3: If it's too late, and the temporary change is already committed, but not tagged. This looks like 2b, except that two steps, "revert the temporary change" and "reapply the temporary change", will have to be done file by file: cvs update -j1.5 -j1.4 foo.c cvs update -j1.17 -j1.16 bar.c and cvs update -j1.4 -j1.5 foo.c cvs update -j1.16 -j1.17 bar.c respectively. More work than if it was tagged, but less than doing the whole merge file by file. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository recovery and archiving
On Fri, Mar 16, 2001 at 10:05:43AM +, Jesus M. Salvo Jr. wrote: Rob Helmer wrote: Doing incremental backups with Amanda, dump, by scripting tar or any other backup system is probably the way to go. In short, I need the transaction capabilities of a database ( going back to "cvs tag" needing to be "all" or "none," not "some" in the event of failure during the operation of "cvs tag" ... since tagging multiple files are not atomic ) in a source control. Then lock the repository while you take the incremental backup. See the "Locks" page in the manual. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SSL?
On Fri, Mar 16, 2001 at 05:18:27PM -0500, Derek R. Price wrote: Larry Jones wrote: Derek R. Price writes: Okay, that makes sense, but couldn't you achieve the same effect with a library? Where the exec would have been, the server's main function gets called and the whole process exits immediately upon return from that function? I don't think so. I'm not a security expert, but my understanding is that any code physically linked into the executable is suspect. Yup. If SSL code is linked into CVS, then a buffer overrun anywhere in CVS has immediate and profound security implications. If the SSL code is running in a separate Unix process, then a buffer overrun in CVS doesn't provide any ways to attack it (though the overrun may still be exploitable in other ways). CVS is linked with RCS and GNU diff as well -- and these are unlikely to ever get as much scrutiny as an SSL library, since on their own they're "obviously" not security-related systems. If SSL is added to the mix, the whole cvs binary must be deemed at least as insecure as GNU diff, even though one needs it to be as secure as SSL is on its own. This is a "chain is only as strong as its weakest link" situation. The (partial) solution is to isolate the security code in its own small chain, with few links, and none that haven't been heavily security-audited. The other problem is a combinatorial explosion in un-understood interactions, some of which may be exploitable -- and a corresponding decrease in any one person's ability to understand the whole thing. Basically, it seems to me that this all boils down to the classic Unix argument for small, cooperating, single-purpose tools as opposed to a big, monolithic, Swiss-army-knife tool; it's just that, as soon as security issues get involved, the stakes suddenly become a lot higher. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merge algorithm
On Tue, Mar 20, 2001 at 01:20:33PM -0800, Pyatt, Scott wrote: Does anyone know for sure if diff3 is called and if not, what is used? Does anyone know if the algorithm is documented? It sure seems to be diff3. See src/rcscmds.c, function RCS_merge(). -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
On Tue, Mar 20, 2001 at 05:20:25PM -0800, Stephen Rasku wrote: Nathan Herring wrote: I'd like to have the option on successive imports to mark as deleted any files that previously existed on that vendor branch that are not in the import. I don't see why this is necessary. If you do: cvs co -r vendor-v2 themodule It will not check out any modules that don't have the vendor-v2 tag. True. For all intents and purposes it is deleted. Not true. If you do: cvs co -r vendor themodule you *will* get the deleted files. You shouldn't. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS import failed
On Wed, Mar 21, 2001 at 10:18:36AM -0500, Fitzgerald, AJ wrote: When trying to import a single directory along with its file contents (html, gifs, etc.) I receive the following error message. [...] unable to write, file a0219.html No space left on device And I know there is plenty of space left. If you're working client/server, some CVS operations copy your files to /tmp on the server machine; I don't whether import is one of these, but the fact that the error isn't complaining about a0219.html,v suggests that this may be happening. Also, don't forget that many Unices reserve N% of the filespace for root, so you'll get "No space left on device" errors at 90% or 95% full. It is only this one directory. I am able to import other directories, its just this one giving me trouble. I don't get this, unless it happens to be a big directory :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update
On Wed, Mar 21, 2001 at 02:54:18PM -0500, Derek R. Price wrote: Rui Cordeiro wrote: Is there any option to tell to the cvs update to ignore the files that are in the repository but not in the working directory. I want to update, in one step, only the files that I have checkout. Don't pass '-d' to update? That'll prevent fetching of un-checked-out directories, but I know of no way to prevent the fetching of un-checked-out files within a directory that *is* checked out. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update
On Wed, Mar 21, 2001 at 03:34:17PM -0600, David H. Thornley wrote: "Derek R. Price" wrote: Eric Siegerman wrote: On Wed, Mar 21, 2001 at 02:54:18PM -0500, Derek R. Price wrote: Rui Cordeiro wrote: Is there any option to tell to the cvs update to ignore the files that are in the repository but not in the working directory. I want to update, in one step, only the files that I have checkout. Without actually bothering to find out myself whether this would work or not, how about cvs update * Only works in "."; doesn't recursively fetch only the checked-out files. Doesn't update checked-out files starting with ".". -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
On Thu, Mar 22, 2001 at 05:18:12PM -0500, Larry Jones wrote: You have to use the new release tag (it's the absence of that tag that indicates that the file should be deleted). So, instead of suggesting -jNET:yesterday -jNET, CVS should be suggesting -jNET:yesterday -jSECOND, for example. If, as someone suggested, "import" were to check in a "dead" revision on the vendor branch, I presume both versions would work. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
On Thu, Mar 22, 2001 at 10:30:19PM -0800, Nathan Herring wrote: Larry writes: How is import supposed to know to do that, though? IF import file does not exist, AND repository file does exist, AND repository file has a branch with the same name as the vendor-tag argument AND that branch has the same version as the branch version specified on import AND the most recent revision on the vendor-tag branch is not marked dead, THEN create a new version on the vendor-tag branch marked as dead END IF What he said! Note that if all of these conditions are met except the last one, ie. the ,v file has an appropriate vendor branch, but the latest revision on that branch is marked "dead", then of course the new release tag should be added to that dead revision -- as happens now for an unchanged "live" file. P.S. Here's a second example: $ mkdir vendor1 $ cd vendor1 $ echo 1vendor1_file1 $ echo 2vendor1_file2 $ cvs import -m first tst vendor1 vendor1_v1 N tst/vendor1_file1 N tst/vendor1_file2 No conflicts created by this import $ mkdir ../vendor2 $ cd ../vendor2 $ echo 1vendor2_file1 $ cvs import -m second tst vendor2 vendor2_v1 N tst/vendor2_file1 $ cd ../vendor1 $ rm vendor1_file1 $ cvs import -D -m third tst vendor1 vendor1_v2 R tst/vendor1_file1 U tst/vendor1_file2 No conflicts created by this import NOTE: It didn't remove vendor2_file1 [NB: this actually said "vendor2_file2"; I've corrected what I assume was a typo -ES ], because, depsite the fact that the import file did not exist, the repository file did not have the original vendor1 tag, and so CVS assumes it wasn't part of this vendor's import and leaves it alone. This is the only part I question -- and I do mean "question"; I'm not asserting that it's wrong, but wondering whether it might be, and asking people to think about it. Should this be based on the import branch number, rather than name? That is: if, in the above example, branch-tags "vendor1" and "vendor2" both referred to branch 1.1.1, then they'd be considered identical for this purpose; vendor2_file1 *would* be deleted during the "third" import. But if "vendor1" and "vendor2" referred to different branches, eg. the vendor2 import had been: $ cvs import -m second -b 1.1.3 tst vendor2 vendor2_v1 then, as Nathan says, vendor2_file1 would *not* be deleted during the "third" import -- indeed, in this specific case, it wouldn't have to be deleted, since it wouldn't be on branch 1.1.1 in the first place. But perhaps that's what Nathan meant by: AND that branch has the same version as the branch version specified on import in which case, all I'm questioning is whether the following condition should go away: AND repository file has a branch with the same name as the vendor-tag argument -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
On Fri, Mar 23, 2001 at 09:19:32AM -0500, Derek R. Price wrote: Nathan Herring wrote: Import knows the name and branch version of the vendor branch, has a list of files to import, and has a list of files already in the repository. This is all it needs to know. Now use the following heuristic: Basically, import would have to look up the tip of the vendor branch before execution to obtain the list of files present during the last import. Not "before execution". Instead, "import" turns into a classic merge(*) -- which I guess "update" already is. So one has to add a scan of the repository directory, and the reading of any repository files that aren't in the directory being imported, but it's still only one-pass. * I mean "merge" here in the traditional "sort/merge" sense, not CVS's "merging revisions" sense -- don't you love overloaded jargon? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 'newbie' here, having a problem with check-out
On Fri, Mar 23, 2001 at 10:12:49AM -0500, Patrick Lynch wrote: [earlier steps consist basically of importing, then checking out into c:/docs with WinCVS] 4.4 committed the c:/docs directory... 4.5 at this point, everything is working fine... 4.6 tried to check out docs from the repository and got the msg: "...*PANIC* adminstration files missing...", You shouldn't need to check out again at this point, merely update. After all, you already have a working directory. Now, if this script isn't quite correct, and what you actually did was: 4.61 delete c:/docs 4.62 try to do a "cvs update" that would give you the result you saw, I think. This certainly would: # import cd c:/docs # compressing 2 dos commands into 1 :-) cvs import ... # make a CVS sandbox, but keep the old c:/docs as a backup cd c:/ cvs co -d docs-cvs ... cd c:/docs-cvs edit commit # forgetting that you should be working in docs-cvs now :-( cd c:/docs edit commit # kaboom! admin files are missing of course. 4.7 this, according to the manual, indicates a bad CVS file... 4.8 I deleted the CVS files from the c:/docs directories and tried to check out again -- no luck, get the same error msg. Yes. Now you've explicitly created the problem it was seeing before; what I'm wondering in the preceding paragraphs is how *else* the same situation (missing c:/docs/CVS subdirectory) could have arisen. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
On Fri, Mar 23, 2001 at 03:41:12PM -0500, Derek R. Price wrote: Eric Siegerman wrote: [if] the ,v file has an appropriate vendor branch, but the latest revision on that branch is marked "dead", then of course the new release tag should be added to that dead revision No it shouldn't. I defer to your (much) greater knowledge of CVS internals. I suggested this *because* it's what happens with unchanged live files, and it seems cleaner to me to treat unchanged files (whether live or dead) in the same way, unless there are reasons to do otherwise -- "make sure special cases really are special" and all that. I'll take your word for it that there are indeed reasons to treat these cases differently. Should this be based on the import branch number, rather than name? Absolutely not. If the same vendor branch name was used in both cases then it should already be an error if they point at different branches. Do you mean where someone does this? cvs import foo vendor1 release1 cvs import -b 1.1.3 foo vendor1 release2 ^ [sic] I wasn't trying to address this case, which is clearly an error, but rather Nathan's Case 2 below. I guess I was unclear. Sorry. On Fri, Mar 23, 2001 at 12:53:25PM -0800, Nathan Herring wrote: CASE 1: Vendors using different vendor branches (not just names). [importing on vendor branch A does *not* check "dead" revisions into vendor branch B] No argument here! CASE 2: Vendors using different names, but same vendor branches. To summarize: cvs import foo vendor1 release1 cvs import foo vendor2 release2 with no -b option either time. After looking into this more closely, it seems each of us is right some of the time :-) Under Nathan's assumption -- that this happened because a user was trying to create a second vendor branch but forgot the -b -- he's right; his proposed behaviour works better. But there's another way this situation can arise (which is the one I was thinking of when I proposed my change): if the user was trying to import a new release into an existing vendor branch, but mistyped the tag name. I'll call this "case 3", even though it's isomorphic to case 2. In case 3, my proposed behaviour works better -- if a file is in release1 but not in release2, the user does *not* want it to appear on what they intended to be the *only* vendor branch. Thus, it shouldn't appear on either actual branch, and my way, it doesn't. But note: - Cases 2 and 3 are both due to user error - Both of them have other problems, which keep them from doing what the user wanted (as opposed to what they mistakenly asked for :-) Thus, it doesn't seem to matter much which way this particular decision goes; it comes down to arguing over which error users are more likely to make. Unless, of course, there are more *non-error* cases; if there are, what's right for those should win over both cases 2 and 3. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rename atomicity
On Fri, Mar 23, 2001 at 11:24:19PM +0100, Assar Westerlund wrote: What the patch below does is introduce an option (`-R') for running without creating any lock-files. This would let any user subvert CVS locking in the interest of "saving time" (famous last words) and potentially corrupt the repository. -R would be safe if: - it could be used *only* on operations that don't change the repository (eg. checkout), and - it arranged that the user not be allowed to commit from the resulting sandbox Failing that, it should be an optional feature chosen at configure time -- and should be disabled by default! -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: strange error message
On Fri, Mar 23, 2001 at 04:50:43PM -0700, Ted Irons wrote: cvs checkout: cannot open directory /volume14/postfix/repo.cvs/postfix/mep/src/Shape: Value too large for defined data type cvs checkout: skipping directory mep/src/Shape I'm running cvs-1.10.8 on solaris2.8 (with binary built for solaris2.7) At a guess, this is your problem. More specifically, it looks as though the binary was compiled on/for a system that only supports small "something"'s (probably 32-bit inode numbers), and the repo is on a filesystem with larger whatever-they-are's (eg. 64-bit inode numbers). Try getting the 1.11 source and compiling it on the server machine. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: EmptyDir in CVSROOT direcotory
On Mon, Mar 26, 2001 at 11:17:29AM -0500, Larry Jones wrote: Once [CVSROOT/Emptydir] has been created (by whatever means), there's no longer any need to have CVSROOT be writable for the sake of Emptydir. Is it also the case that Emptydir itself doesn't need to be writable? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: WinCVS Setup!
On Tue, Mar 27, 2001 at 02:23:59PM -0800, Jerry Nairn wrote: The current source for information about cvs itself used to be scriptics, but is now http://www.cvshome.org . No, scriptics is (still -- but at "dev.scriptics.com", not "www") the TCL site. CVS was at cyclic. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Accidentally merged out code.
On Wed, Mar 28, 2001 at 01:43:57AM -0700, Andy Bradford wrote: trying to convince others that have never used [CVS] before, that suddenly attribute all their problems to it, is difficult and I need reasons. I can't just simply say ``you screwed up.'' I know it's due to human error, but need to make others see this light. :-) "cvs history" can be useful. The only time I ever used it was to prove user error in a case something like this. I can't remember the details, though; sorry. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvswrappers - any better suggestions ?
On Thu, Mar 29, 2001 at 09:26:06AM -0800, Gianni Mariani wrote: SO - I created the following cvswrappers file (all ~700 extensions) that are most likely binary. I got it by scanning my Win drives for all extensions, running 'file' on them and removing any extensions which 'file' reported as 'text'. I've seen extensions that are sometimes binary, sometimes text (eg. MS uses it for some specific binary format, but some freeware packages use it for text). Can't remember offhand what they were; maybe *.inf? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs commit: cannot change mode of file upload.php3: Operation not permitted
Just a guess, but perhaps CVS is trying to remove write permission from the upload.php3 file in your sandbox. It would do this if you had CVS_READ set in your environment; or, I gather, if you're using watches. On Thu, Mar 29, 2001 at 04:30:43PM -0500, Brian Hughes wrote: Hi. I don't understand what is happening here. I get: /usr/local/cvsrepos/leda/httpd/deposit/upload.php3,v -- upload.php3 new revision: 1.3; previous revision: 1.2 done cvs commit: cannot change mode of file upload.php3: Operation not permitted cvs commit: cannot change mode of file upload.php3: Operation not permitted when I commit upload.php3 (and the commit itself works). The file permissions are -rwxrwxr-x1 root Leda 4854 Mar 29 16:14 upload.php3 I am not root, but I belong to the Leda group and the cvs group. The RCS file in the repository is: -rwxrwxr-x1 bhughes cvs 6157 Mar 29 16:14 upload.php3,v I thought it had to do with the ownership of the RCS file in the repository, but that isn't it...I think. I don't even see what CVS is failing to do, much less why it is failing! Any explanation would be very welcome! - Brian Hughes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Bulk-Add
Maybe I've already pointed this out; can't remember, so I'll do it now:
On Wed, Apr 04, 2001 at 09:23:37AM +, schmolle wrote:
$ cd $WORKINGDIR
$ find . \( -type d -name "CVS" -prune \) -o \( -type d -exec cvs add {} \; \)
2/dev/null
$ find . \( -type d -name "CVS" -prune \) -o \( -type f -exec cvs add {} \; \)
2/dev/null
Advantage: This will (iirc) handle file names with spaces [...]
This is the only reason not to use xargs. If you have GNU
findutils installed, though, you can use their xargs safely, as
follows:
$ cd $WORKINGDIR
$ find . \( -type d -name "CVS" -prune \) -o \( -type d -print0 \) | xargs -0 cvs
add 2/dev/null
$ find . \( -type d -name "CVS" -prune \) -o \( -type f -print0 \) | xargs -0 cvs
add 2/dev/null
"find -print0" and "xargs -0" say to delimit the pathnames with
'\0' instead of '\n', and to take all other characters literally;
pathnames with funky characters are thus handled correctly.
ps: I'm writing this code of the top of my head. TEST IT BEFORE YOU USE IT!
Likewise!
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: shooting one's self in the foot.
On Wed, Apr 04, 2001 at 12:16:21PM -0400, Larry Jones wrote: [EMAIL PROTECTED] writes: cvs -d release something cvs checkout something --- Since other developers may have changed (e.g deleted) file/directory structure. There's no need to release and re-checkout, just update with -d. -dP actually, to pick up deleted directories. Of course, that requires you to put something in any directories that are intentionally empty, since CVS can't tell the difference between those and ones that have been deleted. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: shooting one's self in the foot.
On Wed, Apr 04, 2001 at 11:27:28AM -0500, [EMAIL PROTECTED] wrote: Another method is cvs diff, something like: cvs -q diff --brief This gives you a little less extraneous data than does update. But it: 1. doesn't list the junk files 2. doesn't list the files that other people have changed in the meantime 3. still spits out several lines for each changed one, most of which are noise "cvs -nq update" does (1) and (2), and doesn't do (3). I'd argue that the extra info it's giving you isn't "extraneous", but quite important (with the possible exception of the junk files -- sometimes I don't care about those; other times I do -- but he said he wants to see them, so they're not noise to him). -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: New born File Error/Status
On Fri, Apr 06, 2001 at 08:36:06AM +1000, Peter Disiot wrote: Hello All A fellow developer managed to get a new born file error/status. This was done, by: 1 - We were working with binary files at the time. 2 - He removed the file, from cvs, and committed - hence putting it in the Attic? 3 - Did a checkout of this directory and found that the files weren't removed, due to operator error I think/perhaps. 4 - He removed the files, from cvs, and committed - hence putting it in the Attic? 5 - Copied the same file (filename) into the same directory in the sandbox. 6 - Added the new file (essentially the same file) to CVS. I think there was an extra step here, between 6 and 7: 6.5 Deleted the file from the sandbox (but didn't not "cvs rm" it) 7 - Tried to commit and got the "could not commit error new born" The actual error message is: warning: new-born g has disappeared It means that a new file (ie. created and "cvs add"ed but not yet committed) has disappeared from the sandbox. The fact that there was already a deleted version in the Attic probably didn't affect anything -- in other words, things would be the same if steps 1-4 had never occurred -- nor did the fact that it's a binary file. 2) How do we now add the file to CVS? First, get the sandbox back to a known state, with no memory of the problem file: - make sure the problem file is NOT in the sandbox - do a "cvs update problem-file" - do "cvs status problem-file"; the output should look something like: === File: no file problem-file Status: Up-to-date Working revision:No entry for problem-file Repository revision: 1.6 /home/erics/Repos/foo/Attic/problem-file,v (ie. the only thing it *does* know about the file is the deleted version in the Attic) Then start over at step 5; don't do 6.5 this time :-) We have backups of the repo before this occurred. You shouldn't need to go there; this isn't that big a problem. On a side note, How are the files in Repository linked together, as in; If I delete the directory "mydir" from the repository, does CVS still maintain a reference to it. They aren't, at all; CVS doesn't maintain a reference. Except for entries in the history log, it's as though the directory never existed. (This can be construed as a bug or a feature, depending on what you're trying to do at the moment :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
On Fri, Apr 06, 2001 at 03:00:37PM -0400, Larry Jones wrote: You can if you have the GNU versions of find and xargs: find . -print0 | xargs -0 ... (Actually, all you need is GNU xargs: find . -print | tr '\n' '\0' | xargs -0 ... Well, GNU's find and xargs are distributed in the same package (findutils), so this shouldn't be too much of an issue :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: File added;deleted;re added-commit error
On Tue, Apr 10, 2001 at 11:48:21AM -0700, Paddy T wrote: When he tries to commit it now,he gets the commit aborted error. When I see in the rep,I see the newly added file pause.bmp,v with very few characters.I can't check it out;can't commit it. What's the precise error message? What does "cvs status" say? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rename atomicity
On Wed, Apr 11, 2001 at 10:11:18AM -0700, Paul Sander wrote: Due to the way that the filesystem works, if the original is open for reading at the time of the rename, it remains open with the old data, and gets removed when it's closed. So the sandbox gets the correct data. There's a WinNT/2000 server now, isn't there? (I wouldn't use it unless forced, and I haven't been forced, so I haven't bothered keeping up :-) What are Windows's rename semantics? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS bashing?
On Wed, Apr 11, 2001 at 01:04:28PM -0500, Gary Heuston wrote: Someone brought up a site on another mailing list about CVS and its limitations and was citing this as a reason to not use CVS...what do you all think about this? Some of this stuff I have personally witmessed (i.e. large binary file problem, no directory versioning) but I'm curious as to others opinions... Yeah, most of his technical points are pretty valid: CVS does not provide Tree/Dir versioning Support for attaching File Project Meta Data is weak Activities like file renaming are not naturally supported I don't think there'll be much argument about these. He mentions Subversion (http://subversion.tigris.org/index.html). I'm keeping an eye on that too, for all of the above reasons; it looks promising. Bitkeeper (http://www.bitkeeper.com/) has also been mentioned, but it's only semifree. CVS stability can be flaky at times (large binaries) I haven't experienced any flakiness -- at least not with recent versions; it was worse in the past. But then, I haven't put any large binaries into CVS, so I wouldn't know about that. Judging by recent list traffic, though, sure the repo gets big (they don't "diff" very well). Not sure what's "flaky" about it, unless you don't have enough /tmp space (which is arguably a sysadmin problem, not CVS's fault). It's hard to tell whether he means it's flaky specifically with large binaries, or whether they're merely one example. If the former, he may have a point. If the latter, I'd say it's at best an unfair generalization. Merging is very primitive Hmmm. How could it be better? NOT a rhetorical question; I'd really like to know. (I haven't used the commercial ones he's comparing CVS to.) And finally, If you want an answer fast, you can?t rely (or blame) the vendor Not a technical problem. Subversion won't be able to solve it either. Re lack of directory versioning, he says: (This in my opinion is unacceptable) Well, he's right; that is an opinion. Others' opinions differ. The binary-file thing is questionable IMO, and I can't evaluate the merging issue. The rest, though, are indeed valid reasons not to use CVS. Of course there are lots of valid reasons *to* use CVS. As always, it comes down to a tradeoff. That CVS is free software can be either a plus or a minus, it seems to me, depending on one's situation. The standard open-source vs. proprietary debate. (We've all seen it ad nauseum, so lets not go there again now, ok?) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: not-ignoring .exe files
On Sat, Apr 14, 2001 at 12:34:58AM -0400, Larry Jones wrote: Michael Hannemann writes: [putting "!" in CVSROOT/cvsignore doesn't stop ignoring] If you're using a local repository, that should work. If you're using client/server CVS, you're screwed A workaround might be to give every user a ~user/.cvsignore on the client machine that did what you want. (I'm guessing that, being on the client, that file will be listened to. I may be guessing wrong of course...) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Trunk tags that act like branch tags?
On Tue, Apr 17, 2001 at 05:03:21AM -0400, Chris Sherman wrote: I want to pull a particular subset of files found on the main trunk into a newly created pen. You could define the subset as a module, then simply: cvs checkout CmdFiles I could do it in a script, of course, but then that script must be adjusted with every new added or deleted file (if anyone remembers). Doing it as a module still has this problem -- you have to keep CVSROOT/modules up to date. But then, your proposed solution of using a sort-of-branch tag also has to be maintained manually -- you have to remember to tag each new file. If you were able to isolate included files from excluded ones by putting them in separate directories, you could make the "CmdFiles" module just refer to the appropriate directories, and it'd pick up file adds/deletes automatically. But that might distort the source tree too much to be practical. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: removing a directory
On Wed, Apr 18, 2001 at 09:55:17AM +, JavaSoft wrote: How can i delete a drectory (including the contents) from CVS on linux server using wincvs without deleting the directory in my local hard disk ? so it's just delete in the linux not in my local hardisk so i can to re-ADDing the direcotry to the linux again. You can't. You'll have to: - make a backup of the sandbox on your local machine - delete the directory locally - "cvs rm" it - commit - restore from the backup -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: directory addition
On Thu, Apr 19, 2001 at 03:29:26PM +0200, Matthias Kranz wrote: Usage: cvs update [-APdflRp] [-k kopt] [-r rev|-D date] [-j rev] [-I ign] [-W spec] [files...] -d Build directories, like checkout does. Which is pretty unclear. You have to already know what it means to understand it. How about this, which is an abbreviated version of what's in the manual: -d Create directories that are missing from working directory. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: UCE Complaint (Re: applying astyle on commit)
Then may I suggest that you unsubscribe from [EMAIL PROTECTED], and not spam all of *us* with these bounce messages (three of which have appeared in my inbox in the last half hour). Thank you. On Thu, Apr 19, 2001 at 02:59:49PM -0400, Christopher Fogarty wrote: You have sent the attached unsolicited e-mail to my e-mail account. I do not wish to receive such messages in the future. Please remove my name from your lists immediately. --- This message was intercepted by SpamKiller (www.spamkiller.com) --- [ On Thursday, April 19, 2001 at 18:47:33 (+0200), Maarten de Boer wrote: ] Subject: applying astyle on commit So my question is: how can I do this? Doing it client side is not really an option, because we use different platforms, and besides, doing it server-side assures correct usage of astyle. Generally speaking that's way outside the scope of any pure versioning tool. Something like style enforcement is more along the lines of automated policy enforcment in a larger process model. Remember: CVS is not an automated testing program. CVS does not have a builtin process model. If I were you I would switch to using Aegis -- it offers a two-phase commit policy and also offers the ability to require a series of tests to complete on all commits. With Aegis you could arrange things in such a way that one of the tests was a style conformance test or you could do style conformance tests as part of the second commit phase and push any non-conforming changes back to the developer for correction. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Xdelta and CVS
On Thu, Apr 19, 2001 at 03:47:14PM -0500, David H. Thornley wrote: (How rapid [-ly an xdelta-capable CVS was accepted by the world at large] depends partly on how effective the merging was, which is to say whether two changes in a file can be merged to produce another useful file. It would be exactly as effective as it is now (ie. good for text, useless for binary). The merge algorithm is completely orthogonal to the storage format; a merge from an xdelta repo would be done the same way it is now: - check out any needed revisions - point diff3 at them (Well, the implementation might be a bit different. I think those two steps are currently encapsulated within the compiled-in copy of rcsmerge; if so, they'd have to be pulled up into the CVS-proper layer.) The fact that merging and delta generation currently use the same algorithm is a coincidence, and as far as I know, nothing depends on it. This would obviously depend partly on the file format, and I'm not an authority on common binary file formats.) This is therefore an unrelated (albeit frequently debated) issue :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
