Re: How to tell CVS that it should use the proper date/time
hi larry, > > oops, I couldn't find a -d option in cvs' info docus. Perhaps it's still > > not supported in 1.11.5?! > It's mentioned in the Quick Reference, but not in the detailed guide. > It's not new, it's been there "forever". thanks for the hint. Strange that it isn't visible in the info manual! Look like that needs some refinement or update... Anyway, as I see now there doesn't seem to be a comparable option for the add command, though. Only import would allow this, add won't! Am I right? If so, it would be quite strange... Marko ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: coaxing scientists to use cvs
> "Kaz" == Kaz Kylheku <[EMAIL PROTECTED]> writes: Kaz> On Thu, 8 Jul 2004, Hensley, Jeffrey L ERDC-ITL-MS Contractor Kaz> wrote: >> I've been working together with a group of about 6 >> engineers/scientists for over a year. These are all bright >> people, but software engineering is not one of their strong >> suits. That's the problem. They usually won't care anything about software engineering, whatever valid reasons you're selling them. They simply can't understand the concept, and how useful it is. I write academic papers with LaTeX, and find CVS invaluable in keeping track of the variants, esp.the "milestone" revisions submitted to a journal/conference and the final camera-ready versions. Being able to diff between these milestones is so useful. Having a full history of the revisions also means that I can now delete text by really deleting them, rather than keeping a shadow there by only commenting them out (making the source files much longer and polluted with obsolete things). I've been trying to persuade my supervisor to use some version control system for the scientific writings with me. The response is always that he's too busy (lazy) to learn new things. Even when he knows that this is a useful tool, he still refuses to learn it. (Don't ask me why. I can't understand that attitude either.) Then, I asked him to cooperate and ask me for my latest version (which I keep myself with CVS) before he starts editing, and send me his new version when he's done with the editing. He never listened. He just go one with HIS old version and start writing and adding things to it, ignoring what I've added in between. I have to do a tedious and boring merge afterwards when he sends me back his version. Given his uncooperative attitude w.r.t. version controlling, that's the best I can do. What's worse: his LaTeX editor tends to reformat the paragraphs he's editing, making the diff result with my CVS sources bloated with bogus lines, taking me more time to do the merge (even with the handy ediff-merge function of Emacs). I've explained these problems to him. Guess what. He said his time is so valuable that he'd leave all these time-consuming things to me. Translation: you cheap labour do everything in the tedious way; I'm not going to do anything to make the task easier for you (even when it is just a tiny bit extra work for me). How does he do version control himself? He simply does it the old stupid way: cp -r trunk/ some_version/ His home directory is thus full of stuffs. He has the luxury: when disk space runs out, the admin people buy new disks and install and configure the new disk space for him. >> I managed to convince them to start using CVS to try to help >> maintain the scientific package that they are developing. Good luck. Kaz> I say, just leave them alone to do whatever they want. Their Kaz> success is in their own hands. Just don't tie your own Kaz> success to theirs, that's all. Yeah! Don't expect anything on them. If they can do the version control properly, it should be treated as a bonus, not an expectation. -- Lee Sau Dan +Z05biGVm- [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED] Home page: http://www.informatik.uni-freiburg.de/~danlee ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: finding files missing from my workspace
"Paul Gelderblom (ptok)" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I would use > cvs -n update > this will give you the output of cvs update and show you which files would > be replaced locally during a "real" update, but it will *not* do it. > > Having a quick look, I did not find a way to issue this command via the GUI > of Tortoise or WinCvs . You may need to use a command line CVS for this > (which you have installed if you use Tortoise) > > However: > If you install WinCvs next to Tortoise (which is possible provided that you > force them to use the same CVS executable on the client), you will see the > "deleted" files in the folder: they will have a special "broken file" icon. > WinCVS bases this knowledge on the (local) CVS folder, which still contains > infornation on the file you deleted. > > In my experience, Tortoise is a wonderful and easy to use client on the PC, > but in specific cases like these you will need to have Wincvs installed next > to it (or use the command line cvs, whichever you prefer.) > > > Paul Gelderblom > > > > ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: finding files missing from my workspace
(sorry about previous reply - a slip of the finger) "Paul Gelderblom (ptok)" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I would use > cvs -n update > this will give you the output of cvs update and show you which files would > be replaced locally during a "real" update, but it will *not* do it. > > Having a quick look, I did not find a way to issue this command via the GUI > of Tortoise or WinCvs . You may need to use a command line CVS for this > (which you have installed if you use Tortoise) > thanks to both for the reply. Of course, having successfully got the list of files to delete from the command line client, I realised I can't delete them using tortoise unless they exist in my workspace anyway :-)) I must admit I find the namespace client very easy to use, but it never really occured to me before that this is a fundamental problem with a namespace client - if the file isn't in the workspace, you can't do anything with it. Andy ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: coaxing scientists to use cvs
Hi, I also use cvs for LaTeX sources and have the same problem with the diffs. It always depends on how you format your sources. With code it's easier, much easier. Every line contains a certain piece of code. But text source can't be handled in this simple way. I used to write one-line-paragraphs in Emacs to be able to have automatic line wrapping, but doing so leads to huge ,v-files eventually, because a tiny change in a paragraph triggers a complete substitution of the whole thing... If you do the word wrap yourself you have similar problems, just because of a single letter you can still end up with many diffs all over the place... I'd guess CVS is not so well-suited for this job. Of course keeping the revisions is essential, but for the diffs you'd need something else in that case. I recall a certain discussion on this list about other ways of diffing and custom diff programs, though I have to admit I didn't follow that thread. I guess textual content would be such a case where this would come in handy. Right?! Marko ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: up-to-date check failed from a lower revision to higher revis ion
[EMAIL PROTECTED] wrote: > Antony Paul <[EMAIL PROTECTED]> wrote: > > I am new to CVS. I am using the cvs command line client > in Linux. I have > > one file whose status is as follows > > cvs status: Examining . > > === > > File: one.txt Status: Locally Modified > > >Working revision:1.4.1.3 Sat Jul 10 08:53:39 2004 > >Repository revision: 1.4.1.3 > /home/cvsuser/cvsroot/work/base/one.txt,v > >Sticky Tag: 1.4.1 > >Sticky Date: (none) > >Sticky Options: (none) > > It is unconventional to have a numeric sticky tag ... > > >Existing Tags: > > No Tags Exist > > ... and no symbolic tags. Anyway, I'll go one step further: having no symbolic tags when working with branches is plain wrong. Never use numeric revisions for branches. Always use symbolic tags, and don't forget to apply a non-branch tag to the branch point. Never *tell* CVS what revision number to use - let it figure out the numbers. Antony, getting back to your original question: Why do you want to specify the numeric revision? What are you trying to accomplish? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs on Win2x cluster
[EMAIL PROTECTED] wrote: > Has anyone experience with running a cvs server on a Win2x cluster? > We plan to install a version management system on a active-passiv > failover cluster running under Windows 2003. Therefore I am interested > in the ability of cvs to handle Windows messages to stop the process > on one machine and start it on the other machine. I haven't tried the configuration you're suggesting, but CVS has no notion of "Windows messages". It is strictly command-line based. HTH! -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How to create additional repository with pserver
[EMAIL PROTECTED] wrote: > server_args = --allow-root=/first/repository pserver > > This is the line I have in the cvspserver file.So what I > need to add > is:- > > server_args = --allow-root=/first/repository > --allow-root=/second/repository pserver > Is this right? Yes. I assume the word wrapping is an artifact of the mail system, but just in case it isn't: make sure it's all on one line. > I do not have the -f option before pserver. Should I add it now? Have a look at https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_16.html#SEC116 and decide for yourself ;=) For pserver, it probably won't make a difference, but if anyone works locally it could cause difficulties. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How to tell CVS that it should use the proper date/time
marko wrote: > Anyway, as I see now there doesn't seem to be a comparable > option for the > add command, though. Only import would allow this, add won't! > > Am I right? If so, it would be quite strange... The option is not there *because* it is not a good idea to do this. Marko, let me repeat what Frederic asked when you first started this thread: Why do you want to do this? Generally speaking, you should let CVS handle details like the timestamps. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Checkout aborted error on checking out a binary file from cvs
Hello, On checking out an ~6MB file (Wincvs client, Linux server), I get an error saying "cvs [checkout aborted]: end of file from server (consult above messages if any)". There aren't any error messages to consult. The downloaded file seems to be the one that we want, so I can't figure out the reason for the message. Running a trace on the checkout command for this file and another smaller binary file shows similar output except for the last line. The first fails and the second reports success. I'd appreciate any help figuring this out. Thanks, Yamuna ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
CVS web interface
I know there is a threshold on the number of files that can be displayed by the web interface of CVS on windows, for a specific project in a repository. Can someone tell me what it is? Thanks Khyati___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Checking out a branch with -D
I have the following scenario. A new file foo.c was added to the head on Apr 1. On Jun 1 changes on the head were merged to a branch MY_BRANCH that existed prior to Apr 1; in particular foo.c was added to the branch. I now want to recover a working copy of the branch as it existed on May 1. I check out a copy with the command: cvs co -r MY_BRANCH -D "2004-05-01" my_module For some reason I'm getting a copy of foo.c, when foo.c was not part of the branch at that time. Is this the way it's supposed to work? Is there some way of recovering exactly what the branch looked like at that date? (I wish now I had tagged the branch, but I didn't). Thanks! -- Neil Carlson <[EMAIL PROTECTED]> Los Alamos National Laboratory ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs on Win2x cluster
"Jim.Hyslop" wrote: > > [EMAIL PROTECTED] wrote: > > Has anyone experience with running a cvs server on a Win2x cluster? > > We plan to install a version management system on a active-passiv > > failover cluster running under Windows 2003. Therefore I am interested > > in the ability of cvs to handle Windows messages to stop the process > > on one machine and start it on the other machine. > I haven't tried the configuration you're suggesting, but CVS has no notion > of "Windows messages". It is strictly command-line based. > > HTH! I have been working with cvs in a linux 'heartbeat'[1] cluster. For me, the solution was to create a script to stop and start cvs on the correct node, it is working well for me, I just have not had time to get release of the script approved. Perhaps you could create a script or program that can receive the "Windows messages" and appropriately un/configure cvs to run on the node and stop/start the (x)inet like process(es). [1] http://www.linux-ha.org/ -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Checking out a branch with -D
Neil Carlson wrote: > I have the following scenario. A new file foo.c was added to the > head on Apr 1. On Jun 1 changes on the head were merged to a branch > MY_BRANCH that existed prior to Apr 1; in particular foo.c was added > to the branch. I now want to recover a working copy of the branch > as it existed on May 1. I check out a copy with the command: > cvs co -r MY_BRANCH -D "2004-05-01" my_module > For some reason I'm getting a copy of foo.c, when foo.c was not part > of the branch at that time. Is this the way it's supposed to work? Yes, because -D xxx means "the latest revision before xxx". If you want *just* that date, try -D"2004-05-01<2004-05-02". Actually, it shouldn't really be such a big issue, should it? Your makefiles will just ignore the file. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: coaxing scientists to use cvs
[ On Monday, July 12, 2004 at 14:30:48 (+0200), marko wrote: ] > Subject: Re: coaxing scientists to use cvs > > I used to write one-line-paragraphs in Emacs to be able to have automatic > line wrapping, but doing so leads to huge ,v-files eventually, because a > tiny change in a paragraph triggers a complete substitution of the whole > thing... If you do the word wrap yourself you have similar problems, just > because of a single letter you can still end up with many diffs all over > the place... There's more than one reason for letting the markup language / formatter do your paragraph filling for you and to instead always end every sentence (or similar construct) with a newline (and to only wrap long "lines" (sentences) when absolutely necessary). (just as one usually ends every code statment in a program with a newline regardless of whether the language syntax requires whitespace formatting or not) Unfortunately too many emacs edit-mode authors tend to like their text to appear in "pretty-printed" form and they tend to forget that it's better to clearly delineate the structure of the text in the form it is edited (and stored) in. As a result there are few, if any, emacs editing modes for text that do the right thing. (BTW, the old and perhaps original reason for not filling paragraphs in document source text was to avoid having to edit multiple lines unnecessarily with a line-oriented editor. Note that many full-screen editors are still very line-oriented in their editing methodology, such as 'vi' where paragraph pretty-print filling has to be done with an external command.) -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: binary files bad idea? why?
[ On Thursday, July 8, 2004 at 23:01:09 (-0700), Mark D. Baushke wrote: ] > Subject: Re: binary files bad idea? why? > > IF we assume that the 'cvs update' of a particular file in a user's > sandbox needs to do a three-way merge (checked-out version, > latest-version and locally modified version) AND we assume that there is > a "hint" for the CVS server to use some program that looks just like > diff3 as to arguments, but (possibly) interprets (say a canonical HTML > structure ignoring whitespace) the file differently than the default > diff3, AND the "diff3-like-progam" for the checked-out version and the > latest-version specifies the same diff3-like program, THEN Paul's > request for an extension seems reasonable to allow this kind of an > extension. Except those assumptions in total are bogus (and unrealistic), and they do not leave one with a true RCS-compatible repository either. Remember the whole point of RCS compatability is to be compatible with other tools that understand and use the RCS ,v format. It's not just a convenient delta compression mechanism. However the particular form of delta compression used universally in the RCS ,v format is integral to everything I know of which would rely on RCS compatability. If you want to just compress deltas efficiently regardless of the internal structure of the files being versioned then you should use xdelta and give up entirely on the notion of RCS compatability. That way lies ultimate flexibility, but of course it's also the path to ever more waste of computing resources necessary to reconstruct deltas in more sensible forms for both human _and_ computer consumption, wether that's the traditional diff/patch style or some other representation suitable for non-text files, _every_ time they're needed. Also within the architecture of CVS it's totally bogus, stupid, and very short-sighted, to go blindly off and invent yet another ugly brain- damaged hack that doesn't fully account for the fact that some signifiant number of files' "internal structure type" (for lack of a more succinct term) _will_ change over time in any sizable project. CVSwrappers is bad enough for this reason alone already (never mind the other brain-damage it implies) and luckily it's not used by many otherwise sane people. Any extension mechanism _MUST_ be per-delta, but of course that goes against the very nature of RCS (and there are already a vast number of attributes which are not per-revision but should be to get to this level of flexibility). > The lack of support for a per-delta newphrase that tells some version of > CVS to use this other diff3 equivalent would not impact RCS nor would it > impact older versions of CVS. That's not the point -- why would anyone be bothering to use a change control tool in the first place if all they want are archives of revisions with delta compression for storage efficiency?!?!?!? The whole point of doing change control is to capture (and be able to reproduce, undo, copy, merge, etc.) the essense of the changes made, not just to archive various revisions. While one can pretend to do this by reconstructing them every time using "the right tool" and re-extracted copies of "the right revisions", that's (politely speaking) not a very productive direction to go in when one is still using RCS in the back-end. As you full well know there are ample other available tools which are better suited to doing this already too (and one widely used delta compression algorithm to bind many of them together, conceptually at least, if not with repository compatability :-). IMVNSHO (and it has always been so) CVS could and should be making better and more efficient and more effective use of the deltas stored in RCS files, in their direct native format; not less. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: binary files bad idea? why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Greg, It is a pity that you didn't bother to read what I wrote and instead ranted on a question that was not asked. Have you been ill? If so, I am sorry to hear it, please get well soon. Let me put this in simple terms via an exmaple. I was asking if an automated FORM of the following commands (note that locking issues and file permissions and the like would also need to be handled properly, this is just pseudo-code as an example): Given a checked out tree where filename was originally checked out when was the top of the branch, and for which the latest version is now and for which local modifications have been made, run the commands: cvs update -p -r filename > filename. mv filename .#filename. cvs update filename mv filename filename. \ -E -am -L filename -L -L -- \ .#filename. filename. \ filename. > filename.merged mv filename.merged filename and where is some program other than 'diff3', but which accepted idential arguments to diff3. [The above is roughly equivalent to what run_diff3() does in cvs other than that cvs hard-codes the use of the 'diff3' executable instead of allowing for the possibility of using a different executable. Feel free to read the code in rcscmds.c that pertain to this.] The same basic method could be used either to do a simple 'cvs update' on a tree or to do a 'cvs update -jtag1 -jtag2' on a tree. As you should be able to see, there is nothing in the above that is assuming anything about the internal delta formats or any of the other drivel you banged into your keyboard. It has been suggested that the 'diff3-equivalent' command name might be kept in an newphrase section of the delta for each version, but that is not even required for this example code and we could store it outside of the rcs file if there was an excellent reason to do it (even though all of the tools that manipulate rcs files I have been able to find would not have a problem with an extra keyword-value pair). Your entire reply to my previous message did not address any of the points or topic of my message and instead attacked a position I do not hold (by name-calling whoever would hold the positions that were not your own). Honestly, my original message was not intended as flame-bait. If you are not going to even bother to read what I write and not try to read between the lines, you are going to hurt yourself and burst a blood vessel or something... -- Mark Greg A. Woods <[EMAIL PROTECTED]> writes: > [ On Thursday, July 8, 2004 at 23:01:09 (-0700), Mark D. Baushke wrote: ] > > Subject: Re: binary files bad idea? why? > > > > IF we assume that the 'cvs update' of a particular file in a user's > > sandbox needs to do a three-way merge (checked-out version, > > latest-version and locally modified version) AND we assume that there is > > a "hint" for the CVS server to use some program that looks just like > > diff3 as to arguments, but (possibly) interprets (say a canonical HTML > > structure ignoring whitespace) the file differently than the default > > diff3, AND the "diff3-like-progam" for the checked-out version and the > > latest-version specifies the same diff3-like program, THEN Paul's > > request for an extension seems reasonable to allow this kind of an > > extension. > > Except those assumptions in total are bogus (and unrealistic), and they > do not leave one with a true RCS-compatible repository either. Your opinion, while strong, does not address the particulars. > Remember the whole point of RCS compatability is to be compatible with > other tools that understand and use the RCS ,v format. It's not just a > convenient delta compression mechanism. However the particular form of > delta compression used universally in the RCS ,v format is integral to > everything I know of which would rely on RCS compatability. Well, if we were really RCS compatible, we would not have magic branches and CVSNT would not have mergepoint entries in deltas, so the 'whole' point is somewhat less than 'whole'... There are good reasons to follow the RCS format and not be egregiously incompatbile. Nothing that follows the RCS syntax format to add a few newphrase entries could be said to be a tools that is compatible with RCS format. > If you want to just compress deltas efficiently regardless of the > internal structure of the files being versioned then you should use > xdelta and give up entirely on the notion of RCS compatability. That > way lies ultimate flexibility, but of course it's also the path to ever > more waste of computing resources necessary to reconstruct deltas in > more sensible forms for both human _and_ computer consumption, wether > that's the traditional diff/patch style or some other representation > suitable for non-text files, _every_ time they're needed. I missed the leap of subject here. No once have I mentioned the internal representation of cvs files. You are the one who raised xdelta, no
Commit and Add Question.
Hi all, I want to some operations after commit process is done. If I invoke cvs add, I do not do anything. Currently, I add the operation in loginfo file but my operations will get trigger if I run cvs commit or add. If I just want to trigger my operation once the cvs commit is done, how to do it? Thanks. -HS ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
