Re: Checking out without lock
Ed Avis writes: > > Cool, I'll try that. Do you mean 1.12 or some other version not > mentioned on the download page? 1.12. -Larry Jones They say winning isn't everything, and I've decided to take their word for it. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Diff treats files as text after they have been flagged -kb
I'm looking for some help with a problem in binary file handling. We use CVS to control a collection (dozens) of Watcom C/C++ software projects under Windows 98. For most of our work, we interface to CVS through WinCVS 1.2. WinCVS 1.2 incorporates CVS 1.10, if I understand correctly. The Watcom IDE creates and maintains "project" (.WPJ) and "target" (.TGT) files to hold all the project information (e.g. compiler options). These are structured as text files, but are not human readable. When we first set up CVS and imported the software directory structure, we made the mistake of calling the .WPJ and .TGT files "text" files. As a result, when we made changes and then did a diff on the project directory structure, we got pages of useless output showing unintelligible changes to the .WPJ and .TGT files. We now check in new .WPJ and .TGT files as "binary", which eliminates the useless diff output. However this leaves the original .WPJ and .TGT "text" files. I used cvs admin to attach the -kb flag to all the .WPJ and .TGT files both in the repository and the sandbox, expecting this to fix the problem. (This lead to some CR/LF problems when old versions of the .WPJ and .TGT files were checked out, but I was able to write a utility to fix that.) In spite of flagging all the old .WPJ and .TGT files -kb, diff still compares the files as if they were text files. Any suggestions as to how to fix this? I could of course export the whole project and import it into a completely new repository, but I would lose the history in the present repository. -- Jack Dodds R & D Manager Phoenix Geophysics Limited Unit #3 3781 Victoria Park Avenue Scarborough, Ontario, Canada M1W 3K5 Voice 416-491-7340 Fax 416-491-7378 email "Jack Dodds" <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Cannot add file on non-branch tag
> Hi All > > I am trying to add a file on a following specific path on a branch named > "bname" > Though I am able to add a file on some other location path. > The error is - > > cvs server: cannot add file on non-branch tag bname > > I have checked the other files existing on this path are branched, infact > added after branching. > It would appear that "bname" is not a branch on that particular file, but rather a revision tag. CVS maintains information by file, and so it is entirely possible (and usually a problem) to have a tag be a branch tag on one file and a revision tag on another. You can check this with "cvs stat -v ", which will show you all the tags and whether they are branch or revision. (You can do the same with "cvs log", but it's harder to spot the difference.) To fix this, eliminate the existing "bname" tag, and recreate it as a branch tag. Then check with "cvs stat" to see what the sticky tag is, and "cvs update -r bname " if it is wrong. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Cannot add file on non-branch tag
"Gurpreet Singh (SCM)" writes: > > From the command line on the following syntax : > cvs checkout -N -d c:\temp ModuleName > > I get the error CVS/Entries not found... That probably means that c:\temp\ModuleName already exists -- checkout really wants to create a new directory. -Larry Jones Physical education is what you learn from having your face in someone's armpit right before lunch. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs diff, proposal for change
[ On Thursday, September 4, 2003 at 18:25:43 (-0400), Terrence Enger wrote: ] > Subject: Re: cvs diff, proposal for change > > I would not dream of suggesting a change to that. Nor do I suggest > changing anything in the repository, or even in a sandbox. Properly doing what you suggest requires changing the very way RCS files work internally. RCS stores the output of "diff" and relies on the use of newlines to delimit records in a file. If you want to store deltas of binary (opaque structure, non-text) files then you either need to use a means of calculating the differences between versions of such files (e.g. xdelta), or you need to store whole copies of every version of every file. The latter though is totally incongruous with how CVS uses RCS files. If you're going to do the latter then why are you bothering with CVS? The primary goal of the Concurrent Versions System (CVS, aka CVS-II) is its ability to allow "Concurrent" edits of source files. This ability hinges squarely on the way the underlying RCS system calculates deltas of source files and can merge changes with conflict detection. You can _very_ easily build interfaces between your larger SCM and an archive of binary files stored with each file in a uniquely named directory -- it's just naming conventions and you can even use the very same naming conventions you now use with CVS (i.e. serial numbers for un-named revisions and the same tag names for named revisions). > Yes, but (in my best, 3-year-old, obnoxious whine) ... > (1) I have some familiarity with cvs, and I am learning to > like it more all the time. What you are hopefully learning to like about CVS is not possible to achieve with opaque-structured binary files and not possible to achieve using RCS as the repository format with any non-text files (regardless of how well you understand the structure of those files and regardless of how many tools you may already have which can detect changes in such files in a structured manner -- if you don't modify RCS you cannot meaningfully store deltas to any such files and thus you cannot meaningfully merge changes between different versions that were derrived from the same ancestor). > (2) I have binary files, and lack of version > control of binary files has wasted too much of my > time. > Just like any 3-year-old, I don't want to admit that I am > SOL. You're not really SOL -- it just looks like it until you learn to think a little outside the box you've built around your current thoughts. 1. keep your binary files in a separate manually managed archive. 2. use smart naming conventions for that archive which directly map, or can be mechanically mapped, onto the same naming conventions you use for your text files in CVS. Lots of us have very successfully used this approach to managing change in files we cannot store meaningfully in CVS. If, for example, you use "make" or some other scripting language to build your sources then the integration of this management is done by changing the version names used in makefiles or the build scripts to reference the binary archives and thus you can still track the changes to the references of those binary archives in CVS. If you have some other tools which allow you to track internal changes to those binary files in some way that's meaningful for those files and for your project then by all means please do use those tools on your separate archive of binary files. > cvs already supports binary files to the extent of offering > -kb. "CVS supports binary files"?!?!?!? No, I don't think so. The '-kb' "sticky flag" is just a terribly bad hack that gets more people into more trouble with CVS than you could ever imagine because it gets mis-interpreted as doing what you think it does. It was not intended for that purpose at all and it does not work the way you think it does. DO NOT try to store binary files in CVS. > And Herr Klauer's files are binary only in the sense > that different patterns look the same on the screen. Yeah, sure, but unless you can calculate deltas between them in a meaningful way and then store those deltas in an RCS file in the same way RCS diffs text files, then you can't manage changes to such files using tools like RCS and thus CVS. This is ever more critical for CVS since of course CVS relies on being able to merge changes made to two different derrivative versions of the same file and to detect potential conflicts in those changes and mark them up in some way that the user can resolve the (apparent) conflict(s). > Would > the objection to the proposal still stand if I could submit > a patch? (I am not planning to do that soon, and probably > not at all; just probing for the roots of the objection.) I find it very counter-productive to discuss superficial changes that would give only the appearance of handling non-text files. That's what '-kb' has lead to and nothing good at all has come of it over the years. --
RE: Cannot add file on non-branch tag
Thanks ..
well one more query :
>From the command line on the following syntax :
cvs checkout -N -d c:\temp ModuleName
I get the error CVS/Entries not found... Fine I understand but want to make
sure that are the switches / option I am using are appropriate ? Its not
creating the CVS folder (entries / root / ...etc files) so it doesnt gets
the code.
My requirement from the syntax that I should get / checkout the code on a
specific path (say c:\temp).
Any suggestions pls
Regards
Gurpreet S
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 8:08 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Cannot add file on non-branch tag
"Gurpreet Singh (SCM)" writes:
>
> I am trying to add a file on a following specific path on a branch named
> "bname"
> Though I am able to add a file on some other location path.
> The error is -
>
> cvs server: cannot add file on non-branch tag bname
That implies that "bname" is a revision tag rather than a branch tag in
at least one file in the directory. For safety's sake, CVS considers a
tag that occurs both as a branch tag and as a revision tag to be a
revision tag. You can use "cvs status -v" to find the culprits. If the
tagged revision is the correct root for the branch, you can convert the
revision tag to a branch tag with "cvs tag -Fb". Once the tags are
corrected, you'll need to re-update the working directory to the branch
so that CVS knows it's now a branch tag ("cvs up -rbname").
-Larry Jones
It's going to be a long year. -- Calvin
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and gdbm?
[EMAIL PROTECTED] wrote: > The CVS FAQ says: > > By default, the `modules' file behaves as described above. If the > modules file is very large, storing it as a flat text file may make > looking up modules slow (I'm not sure whether this is as much of a > concern now as when CVS first evolved this feature; I haven't seen > benchmarks). Therefore, by making appropriate edits to the CVS source > code one can store the modules file in a database which implements the > ndbm interface, such as Berkeley db or GDBM. If this option is in use, > then the modules database will be stored in the files `modules.db', > `modules.pag', and/or `modules.dir'. > > Is there any further info on configuring CVS to use gdbm? Especially, > benchmarks? No benchmarks, but the "appropriate edits" to use gdbm exist in the Cygwin package of cvs. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Cannot add file on non-branch tag
"Gurpreet Singh (SCM)" writes:
>
> I am trying to add a file on a following specific path on a branch named
> "bname"
> Though I am able to add a file on some other location path.
> The error is -
>
> cvs server: cannot add file on non-branch tag bname
That implies that "bname" is a revision tag rather than a branch tag in
at least one file in the directory. For safety's sake, CVS considers a
tag that occurs both as a branch tag and as a revision tag to be a
revision tag. You can use "cvs status -v" to find the culprits. If the
tagged revision is the correct root for the branch, you can convert the
revision tag to a branch tag with "cvs tag -Fb". Once the tags are
corrected, you'll need to re-update the working directory to the branch
so that CVS knows it's now a branch tag ("cvs up -rbname").
-Larry Jones
It's going to be a long year. -- Calvin
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checking out without lock
Ed Avis writes: > > I have read access to the CVS repository but no write access. > Obviously this means I cannot commit any changes. But it ought to be > possible to get a checkout. However even if I turn off history > logging, cvs co won't work because it wants to make a lock file. If you want to allow read-only access to a repository, you need to use LockDir= in CVSROOT/config to point to a separate lock directory (outside the repository) that everyone can write to (and you really should set the permissions on the history file to let everyone write to it, too, although you can make it append-only if your OS supports that concept). If the entire repository is really read-only and there's nothing you can do about it, the current development version of CVS has a -R global option to deal with it. -Larry Jones I think my cerebellum just fused. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS and gdbm?
The CVS FAQ says: By default, the `modules' file behaves as described above. If the modules file is very large, storing it as a flat text file may make looking up modules slow (I'm not sure whether this is as much of a concern now as when CVS first evolved this feature; I haven't seen benchmarks). Therefore, by making appropriate edits to the CVS source code one can store the modules file in a database which implements the ndbm interface, such as Berkeley db or GDBM. If this option is in use, then the modules database will be stored in the files `modules.db', `modules.pag', and/or `modules.dir'. Is there any further info on configuring CVS to use gdbm? Especially, benchmarks? luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Cannot add file on non-branch tag
Hi All I am trying to add a file on a following specific path on a branch named "bname" Though I am able to add a file on some other location path. The error is - cvs server: cannot add file on non-branch tag bname I have checked the other files existing on this path are branched, infact added after branching. Suggestions pl. Regards Gurpreet S ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs diff, proposal for change
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Wednesday, September 3, 2003 at 13:07:52 (-0400), Terrence Enger wrote: ] >> Subject: cvs diff, proposal for change >> >> In general, the concensus of those in the know has been >> negative: cvs diff is so far from working with arbitrary files >> that it is not even worth thinking about changing it. >> Nevertheless, I beg your indulgence as I put forward this >> preliminary proposal for changes. >"cvs diff" itself is just the very tip of the iceberg. >The same text-based delta algorithms go right to the core of how RCS >files work. While it is true that the same algorithms are used for two purposes (computing RCS deltas and presenting differences to users), what's really happening is that the diff program just happens to be invoked in two distinct sections of the CVS application. In the section that maintains the RCS file format, the diff program absolutely must be used. But in the other part, the part that displays differences to the user, any tool will do, and in fact the diff program is sometimes the wrong one to use. In other words, I don't believe anyone who says "replace diff" really means "do a global search for the string d-i-f-f and replace all occurances with something else." Instead, I think they really mean to leave the part that maintains the RCS file format alone, and replace the diff program only where it produces user-visible output that is not interpreted by the CVS application itself. >If you want to store abitrary (and especially unstructured) binary data >in a version control system then CVS (and RCS) never was, and never will >be, an appropriate choice for your purposes. There are plenty of unmergeable, text-based file formats. I think you'll find that using RCS to archive such files is no less efficient than using e.g. tar, and you still get the benefits of RCS labelling and branching and revision states. 'Course, unmergeable files don't lend themselves to a concurrent development paradigm by definition, so any arguments that relate to that are moot because there's no expectation for it to work. On the other hand, there also exist mergeable binary types, and CVS should support those. Naturally they don't lend themselves to any text-based diff, and other tools that produce meaningful representations of differences should be used instead. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Cannot add file on non-branch tag
Hi All I am trying to add a file on a following specific path on a branch named "bname" Though I am able to add a file on some other location path. The error is - cvs server: cannot add file on non-branch tag bname I have checked the other files existing on this path are branched, infact added after branching. Suggestions pl. Regards Gurpreet S ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checking out without lock
> I have read access to the CVS repository but no write access. > Obviously this means I cannot commit any changes. But it ought to be > possible to get a checkout. However even if I turn off history > logging, cvs co won't work because it wants to make a lock file. > > Is there some option similar to -l to say do not make lock files when > reading? This means you could get an inconsistent checkout when > someone updates the repository while you're reading, but that is a > risk anyway for projects with more than one directory, and a risk I'm > willing to take. > Not that I know of. The correct solution is for the administrator to set up separate lock directories, with a line like LockDir=/usr/cvs/cvslocks in the CVSROOT/config file. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: pserver handle multiple requets?
> hi, > can pserver handle multiple requests(say 15 - 20) at the same > time? > Always did whan I was administering it. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: slow list? [Was: Re: cvs diff, proposal for change]
[ On Thursday, September 4, 2003 at 18:24:51 (+0200), Andreas Klauer wrote: ] > Subject: slow list? [Was: Re: cvs diff, proposal for change] > > Is it just me or is the mailing list extremely slow? Unless you've been living under a rock for the past month you'll know that there's another major rash of rather nasty e-mail viruses and worms going around in the M$ OS world. Unfortunately these new strains seem to be causing a lot of more bounces to be returned and since "gnu.org" exists in one heck of a lot of people's address books, and since these worms all use forged sender addresses gleaned from address books, the result has been a deluge of mail on the gnu.org, fsf.org, and prep.ai.mit.edu mailers (which among many other tasks also handle lists like this one). A post-script note was attached to an announcement sent out to the developers on the gnu-prog list recently to let us all know about the extent of the problem and to let us know that time it was taking to deal with the worm traffic was adversely affecting the efforts to clean up after the gnuftp and fencepost cracks. I suppose a note about this could have been sent out to all the other lists too. Of course this wouldn't be such a big problem (even in the fact of the inevitable worms and viruses) if really ignorant software designers weren't allowed to write programs that handle e-mail. Far too many virus checkers and broken-by-design mailers are sending bounce messages instead of outright rejecting unwanted messages at the initial SMTP connection. All these extra unnecessary bounces are drastically affecting even those of us who are aware enough of the risks that we don't ever dare run any M$ software. > I first thought it was a problem with my mail provider, but you're the second > person on the list now who sent mails twice, which tells me that other people > seem to have this problem, too. You should know that e-mail only rarely ever gets lost (unless your mailer is really royally screwed up, or unless your mail looks a lot like it contains a virus payload a receiveing mailer along the way decides to silently drop it in the bit bucket instead of rejecting it immediately during SMTP). You shouldn't try resending anything until either you've recieved a bounce message or at least a week has gone by since you tried to post (many mailers will keep trying for 5-7 days before they send you the bounce, though the three days necessary to get past a long weekend is a more common delay). -- 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://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs diff, proposal for change
On 3 Sep, Terrence Enger wrote: > (*) "cvs diff" and "cvs rdiff" accept optional arguments > --filter1=, --filter2=, > --filter-both=. Allow Unix-style pipelining of simple commands to extend diff functionality? Excellent idea! luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
