CVS corrupts binary files ...
Hi all, I've created a simple repository on a Linux server with one module wich is a web site. My working directory is on a Windows machine and I have to use ssh to connect to the server. I've tried several ssh clients and with all of them the checkout command creates corrupted image files in my working directory. The module has been imported on the Linux server, from the server, and the checkout is done from the Windows machine. If I just copy the images with WinSCP they are ok. If I import them (on Linux) and then check them out (on Windows) the images get corrupted Also text files do not transfer properly; there's a strange square at the end of the lines after checkout. Again copying with WinSPC is ok... I thought maybe the ssh client does LF<->CR/LF mapping, but I've tried several, including OpenSSH, and thingd didn't change. Must I tell explicitly to cvs that I transfer text/binary files between different systems ? Or maybe I can't have sources on Windows and Linux in the same time and cvs to function correctly ? Thank you Timothy Madden __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adrian Constantin <[EMAIL PROTECTED]> writes: > I've created a simple repository on a Linux server > with one module wich is a web site. My working > directory is on a Windows machine and I have to use > ssh to connect to the server. I've tried several ssh > clients and with all of them the checkout command > creates corrupted image files in my working directory. > The module has been imported on the Linux server, from > the server, and the checkout is done from the Windows > machine. > > If I just copy the images with WinSCP they are ok. > If I import them (on Linux) and then check them out > (on Windows) the images get corrupted > > Also text files do not transfer properly; there's a > strange square at the end of the lines after checkout. > Again copying with WinSPC is ok... > > I thought maybe the ssh client does LF<->CR/LF > mapping, but I've tried several, including OpenSSH, > and thingd didn't change. > > Must I tell explicitly to cvs that I transfer > text/binary files between different systems ? Yes, for binary files. See the -kb switch. > Or maybe I can't have sources on Windows and Linux in > the same time and cvs to function correctly ? No. Sources which are text files will handle the line endings properly for the client. You are describing a problem with binary files. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAwWvW3x41pRYZE/gRApLPAKDX0WGqqbk/IXrayPtNyBFQ1Oiu5QCgka7J fj85gJI5pf+bjpcLRTHMIog= =wrTy -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
And to make the -kb automatic with binary file types, modify your cvswrappers file... https://www.cvshome.org/docs/manual/cvs-1.11.16/cvs_18.html#SEC166 > -Original Message- > From: [EMAIL PROTECTED] [mailto:info-cvs- > [EMAIL PROTECTED] On Behalf Of Mark D. Baushke > Sent: Friday, June 04, 2004 11:45 PM > To: Adrian Constantin > Cc: [EMAIL PROTECTED] > Subject: Re: CVS corrupts binary files ... > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Adrian Constantin <[EMAIL PROTECTED]> writes: > > > I've created a simple repository on a Linux server > > with one module wich is a web site. My working > > directory is on a Windows machine and I have to use > > ssh to connect to the server. I've tried several ssh > > clients and with all of them the checkout command > > creates corrupted image files in my working directory. > > The module has been imported on the Linux server, from > > the server, and the checkout is done from the Windows > > machine. > > > > If I just copy the images with WinSCP they are ok. > > If I import them (on Linux) and then check them out > > (on Windows) the images get corrupted > > > > Also text files do not transfer properly; there's a > > strange square at the end of the lines after checkout. > > Again copying with WinSPC is ok... > > > > I thought maybe the ssh client does LF<->CR/LF > > mapping, but I've tried several, including OpenSSH, > > and thingd didn't change. > > > > Must I tell explicitly to cvs that I transfer > > text/binary files between different systems ? > > Yes, for binary files. See the -kb switch. > > > Or maybe I can't have sources on Windows and Linux in > > the same time and cvs to function correctly ? > > No. Sources which are text files will handle the line > endings properly for the client. You are describing a > problem with binary files. > > -- Mark > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.3 (FreeBSD) > > iD8DBQFAwWvW3x41pRYZE/gRApLPAKDX0WGqqbk/IXrayPtNyBFQ1Oiu5QCgka7J > fj85gJI5pf+bjpcLRTHMIog= > =wrTy > -END PGP SIGNATURE- > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
--- Peter Connolly <[EMAIL PROTECTED]> wrote: > And to make the -kb automatic with binary file > types, modify your > cvswrappers file... > > > > > > > Must I tell explicitly to cvs that I transfer > > > text/binary files between different systems ? > > > > Yes, for binary files. See the -kb switch. > > > > > Or maybe I can't have sources on Windows and > Linux in > > > the same time and cvs to function correctly ? > > > > No. Sources which are text files will handle the > line > > endings properly for the client. You are > describing a > > problem with binary files. > Thank you. After hours of tests I got it to work. For the begining... Too dificult to set up, I think Shouldn't cvs have a list of binary file types preinstalled in the cvswrappers ? Or maybe projects for Unix/Linux platforms do not usualy have binary files, but I don't really think so... __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adrian Constantin <[EMAIL PROTECTED]> writes: > --- Peter Connolly <[EMAIL PROTECTED]> wrote: > > And to make the -kb automatic with binary file > > types, modify your > > cvswrappers file... > > > > > > > Must I tell explicitly to cvs that I > > > > transfer text/binary files between > > > > different systems ? > > > > > > Yes, for binary files. See the -kb switch. > > > > > > > Or maybe I can't have sources on Windows > > > > and Linux in the same time and cvs to > > > > function correctly ? > > > > > > No. Sources which are text files will handle > > > the line endings properly for the client. > > > You are describing a problem with binary > > > files. > > > > Thank you. > After hours of tests I got it to work. > For the begining... > > Too dificult to set up, I think You may wish to choose a tool that is better for your particular needs. cvs is not at that friendly at controlling and merging binary files. > Shouldn't cvs have a list of binary file types > preinstalled in the cvswrappers ? Checking in binary files is not encouraged for cvs use. > Or maybe projects for Unix/Linux platforms do > not usualy have binary files, but I don't really > think so... Unix/Linux platforms don't really have the same problems converting to/from binary non-binary that windows do. You may wish to consider CvsNt.org as a 'better' variation on cvs as more attention is paid to the Windows platform. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAwiD73x41pRYZE/gRAmSQAJ9eFyzZKWKAATcZdlgI/d9GgGPMfACcD3sc 1Jt+KfMt6FF/ZH9VIvTepfI= =Uqbs -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
--- "Mark D. Baushke" <[EMAIL PROTECTED]> wrote: > Adrian Constantin <[EMAIL PROTECTED]> > writes: > > After hours of tests I got it to work. > > For the begining... > > > > Too dificult to set up, I think > > You may wish to choose a tool that is better for > your particular needs. cvs is not at that friendly > at controlling and merging binary files. I do wish to choose a better tool, but it doesn't exists. They say if you wanna do something right, you have to do it yourself. I don't wanna merge binary files, and I'm not likely to modify them in my module (project). I just want cvs to carry them along with the sources > > Shouldn't cvs have a list of binary file types > > preinstalled in the cvswrappers ? > > Checking in binary files is not encouraged for cvs > use. Well what can I do ? It happends that my project (a web site) includes binary files... > You may wish to consider CvsNt.org as a 'better' > variation on cvs as more attention is paid to the > Windows platform. Well I will..., but I still have a Linux server carring the repository and the release and 2 Windows workstations where I work Thank you Constantin Adrian __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adrian Constantin <[EMAIL PROTECTED]> writes: > --- "Mark D. Baushke" <[EMAIL PROTECTED]> wrote: > > > Adrian Constantin <[EMAIL PROTECTED]> > > writes: > > > After hours of tests I got it to work. > > > For the begining... > > > > > > Too dificult to set up, I think > > > > You may wish to choose a tool that is better for > > your particular needs. cvs is not at that friendly > > at controlling and merging binary files. > > I do wish to choose a better tool, but it doesn't > exists. They say if you wanna do something right, you > have to do it yourself. > > I don't wanna merge binary files, and I'm not likely > to modify them in my module (project). I just want cvs > to carry them along with the sources That is probably okay with the existing cvs. > > > Shouldn't cvs have a list of binary file types > > > preinstalled in the cvswrappers ? > > > > Checking in binary files is not encouraged for cvs > > use. > > Well what can I do ? It happends that my project (a > web site) includes binary files... Discussions of various problems with binaries and cvs have been a frequent topic in the info-cvs mailing list. You may find it useful to look at the archive. > > You may wish to consider CvsNt.org as a 'better' > > variation on cvs as more attention is paid to the > > Windows platform. > > Well I will..., but I still have a Linux server > carring the repository and the release and 2 Windows > workstations where I work The CvsNt.org tool may be compiled and run on a Linux server. The WinCVS client is said to work well on windows with the cvsnt executable. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAwis53x41pRYZE/gRAglxAJ0SGn8cpBwt6LMUEWn2URQCQos8TwCgn57c 6HB1QB6gtVludlC2nsEF2Cs= =AMoP -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
> Too dificult to set up, I think > Shouldn't cvs have a list of binary file types > preinstalled in the cvswrappers ? I agree, it should. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
> You may wish to choose a tool that is better for > your particular needs. cvs is not at that friendly > at controlling and merging binary files. Actually, if there are a lot of binary files in your repository, you might want to consider switching to Subversion (http://subversion.tigris.org/) since it mimics many of the CVS commands; has better support for binary files; and there is a conversion script (http://cvs2svn.tigris.org/). pc ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
> Too dificult to set up, I think > Shouldn't cvs have a list of binary file types > preinstalled in the cvswrappers ? I agree, it should. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
> You may wish to choose a tool that is better for > your particular needs. cvs is not at that friendly > at controlling and merging binary files. Actually, if there are a lot of binary files in your repository, you might want to consider switching to Subversion (http://subversion.tigris.org/) since it mimics many of the CVS commands; has better support for binary files; and there is a conversion script (http://cvs2svn.tigris.org/). pc ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
Adrian Constantin writes: > > Or maybe projects for Unix/Linux platforms do not > usualy have binary files, but I don't really think so... CVS is a *source* control system; source files are rarely binary. It does support them as an afterthought, but that's not what it was designed to do. -Larry Jones I hate it when they look at me that way. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >Adrian Constantin writes: >> >> Or maybe projects for Unix/Linux platforms do not >> usualy have binary files, but I don't really think so... >CVS is a *source* control system; source files are rarely binary. I disagree with this statement. Source files are any files that cannot be reproduced automatically. That is, changes must be made to them manually using some editor, and that editor need not be the likes of vi or emacs. MS Word (or Frame Maker) documents, images of various formats, and documents from various design tools (e.g. GUI builders) are common examples. >It >does support them as an afterthought, but that's not what it was >designed to do. While this may be true, it turns out that CVS' design can accomodate such files. Support can be added with a relatively small amount of effort, which was demonstrated circa Sept. 18, 2001 in this forum in the form of a patch of the then-current release. All that's needed is a pluggable diff/merge tool based on the type of data. And before someone rehashes the old "you can't replace diff without breaking RCS" argument, remember that I'm not recommending replacing the algorithm that computes the deltas. This is strictly a UI thing in the top layer that is well outside the back-end design. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
Is it a proven thing that CVS can corrupt a binary file if no merges are tried and no CR/LF boundary rules are broken? In other words, if I set -kb on a binary file and then do nothing to it but commit updates and sometimes request an old revision, keeping my sandbox in the OS in which it was checked out, could I ever get a bad result? This discussion of binary files has gone on a long time, but either I missed the answer to this, or I never saw it stated. If Greg Woods is reading this, you implied it once in a rather angry message. I welcome the proof, preferably without the anger. On Sat, Jun 05, 2004 at 05:10:58PM -0700, Paul Sander wrote: > >--- Forwarded mail from [EMAIL PROTECTED] > > >Adrian Constantin writes: > >> > >> Or maybe projects for Unix/Linux platforms do not > >> usualy have binary files, but I don't really think so... > > >CVS is a *source* control system; source files are rarely binary. > > I disagree with this statement. Source files are any files that cannot > be reproduced automatically. That is, changes must be made to them > manually using some editor, and that editor need not be the likes of > vi or emacs. MS Word (or Frame Maker) documents, images of various > formats, and documents from various design tools (e.g. GUI builders) > are common examples. > > >It > >does support them as an afterthought, but that's not what it was > >designed to do. > > While this may be true, it turns out that CVS' design can accomodate > such files. Support can be added with a relatively small amount of > effort, which was demonstrated circa Sept. 18, 2001 in this forum in > the form of a patch of the then-current release. All that's needed is > a pluggable diff/merge tool based on the type of data. > > And before someone rehashes the old "you can't replace diff without > breaking RCS" argument, remember that I'm not recommending replacing > the algorithm that computes the deltas. This is strictly a UI thing > in the top layer that is well outside the back-end design. > > >--- End of forwarded message from [EMAIL PROTECTED] > > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/info-cvs -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "It is not the mountain in the distance which makes you want to stop walking; but the grain of sand in your shoe." --Anon ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
--- Paul Sander <[EMAIL PROTECTED]> wrote: > > >Adrian Constantin writes: > >> > >> Or maybe projects for Unix/Linux platforms do not > >> usualy have binary files, but I don't really > think so... > > >CVS is a *source* control system; source files are > rarely binary. > > I disagree with this statement. Source files are > any files that cannot > be reproduced automatically. That is, changes must > be made to them > manually using some editor, and that editor need not > be the likes of > vi or emacs. MS Word (or Frame Maker) documents, > images of various > formats, and documents from various design tools > (e.g. GUI builders) > are common examples. > I tend to see this as a serious break in the cvs design . Today it is not relistic to assume serious projects with many developers involved will only contain text files. Also note that diff has the same problem, only for diff it might not be as acute as for cvs. Please note this problem is legacy since the days computer graphics were an advanced technology. When computers were text-based I can understand binary source files were a strange thing in any project. I would have expected things to evolve. I think there are some binary diff algorithms... > >It > >does support them as an afterthought, but that's > not what it was > >designed to do. > > While this may be true, it turns out that CVS' > design can accomodate > such files. Support can be added with a relatively > small amount of > effort, which was demonstrated circa Sept. 18, 2001 > in this forum in > the form of a patch of the then-current release. > All that's needed is > a pluggable diff/merge tool based on the type of > data. > The design itself does not needs litte changes. cvs design can perfectly acomodate binary sources. It just has to be done (or implemented). I think someday I'll use Subversion... when I'll have the time to take it from the begining and start testing and evaluating it as I've done with cvs Adrian Constantin --- And I don't wanna miss a thing __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Doug Lee <[EMAIL PROTECTED]> writes: > Is it a proven thing that CVS can corrupt a binary file if > no merges are tried and no CR/LF boundary rules are > broken? No. > In other words, if I set -kb on a binary file and then do > nothing to it but commit updates and sometimes request an > old revision, keeping my sandbox in the OS in which it was > checked out, could I ever get a bad result? I have not ever noticed such a bad result. I have noticed non-optimal checkout and commit performance of binary versions of files when the ,v file starts to exceed a few hundred megabytes. If the server is not properly configured with lots of memory and temporary space, there can be problems doing checkouts of lots of files of this type. > This discussion of binary files has gone on a long time, > but either I missed the answer to this, or I never saw it > stated. If Greg Woods is reading this, you implied it once > in a rather angry message. I welcome the proof, preferably > without the anger. The problem arises when two users concerntly modify a binary file. After the first user commits, the second is stuck with trying to figure out how to merge in the other set of changes by hand with no help. Advisory locking 'cvs watch' and 'cvs edit' is typically done for binary files for this reason. Adrian Constantin <[EMAIL PROTECTED]> writes: > > >Adrian Constantin writes: > > >> > > >> Or maybe projects for Unix/Linux platforms > > >> do not usualy have binary files, but I > > >> don't really think so... > > > > >CVS is a *source* control system; source > > >files are rarely binary. > > > > I disagree with this statement. Source files > > are any files that cannot be reproduced > > automatically. That is, changes must be made > > to them manually using some editor, and that > > editor need not be the likes of vi or emacs. > > MS Word (or Frame Maker) documents, images of > > various formats, and documents from various > > design tools (e.g. GUI builders) are common > > examples. > > I tend to see this as a serious break in the > cvs design . Many people do. This is why I and others consistently suggest that cvs may not be the best source control system for general use. > Today it is not relistic to assume serious > projects with many developers involved will > only contain text files. It is realistic to suggest that cvs is not optimized for many kinds of 'serious' projects with constraints of using binary files as a part of the 'source' to be controlled. svn, monotone, gnu arch and others have all arisen more recently than cvs and try in various ways to address the legacy problems that cvs continues to have. > Also note that diff has the same problem, only > for diff it might not be as acute as for cvs. It is bacically the same problem given that diff is being used internally to store deltas between versions. > Please note this problem is legacy since the > days computer graphics were an advanced > technology. When computers were text-based I > can understand binary source files were a > strange thing in any project. Possibly. We have always had binary objects, but many of them have source formats that are compatible with the older text-based representations. It is just that most folks choose not to save the files in those formats for source control. > I would have expected things to evolve. Things have evolved. > I think there are some binary diff algorithms... Indeed. Consider svn which uses xdelta internally. To be fair, CvsNt also has ways of dealing better with binary formats than the cvshome version. There is a hope that we can move toward merging the feature sets between those two major varitions of cvs over time, but it will likely take a bit of time as no one is being funded full time to work on just cvs development. > > >It does support them as an afterthought, but > > >that's not what it was designed to do. > > > > While this may be true, it turns out that CVS' > > design can accomodate such files. Support can > > be added with a relatively small amount of > > effort, which was demonstrated circa Sept. 18, > > 2001 in this forum in the form of a patch of > > the then-current release. All that's needed is > > a pluggable diff/merge tool based on the type > > of data. > > >The design itself does not needs litte >changes. cvs > >design can perfectly acomodate binary >sources. It just has to be done (or >implemented). Should I look forward to seeing your patches to help out on the project? They would be looked at with favor by all of your fellow cvs users. >I think someday I'll use Subversion... when >I'll have the time to take it from the >begining and start testing and evaluating it >as I've done with cvs Yup, svn is the next likely step for a lot of folks. It is a good product and getting more and more features and stability all the time. -- Mark -BEGIN PGP S
Re: CVS corrupts binary files ...
> Doug Lee <[EMAIL PROTECTED]> writes: > > > Is it a proven thing that CVS can corrupt a binary > file if > > no merges are tried and no CR/LF boundary rules > are > > broken? > > No. I got it. It will corrupt my files in the default configuration after instalation, until I tell it that .gif files are not text > svn, monotone, gnu arch and others have all arisen > more recently than cvs and try in various ways to > address the legacy problems that cvs continues to > have. > > > I think there are some binary diff algorithms... > > Indeed. Consider svn which uses xdelta internally. > > To be fair, CvsNt also has ways of dealing better > with binary formats than the cvshome version. > There is a hope that we can move toward merging > the feature sets between those two major varitions > of cvs over time, but it will likely take a bit of > time as no one is being funded full time to work > on just cvs development. > So I see there are many alternatives available, but cvs has not changed. Looks like developers want to offer their new products and not to support the original cvs :( Very sad to find out about this This is so strange and such a bad thing ... > > > > >The design itself does not needs litte > >changes. cvs > > > >design can perfectly acomodate binary > >sources. It just has to be done (or > >implemented). > > Should I look forward to seeing your patches to > help out on the project? They would be looked at > with favor by all of your fellow cvs users. Well I write PHP now. I think there's a long way from web pages to a serious public application I hope I'll study xdelta in the near future Adrian Constantin And I don't wanna miss a thing __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >Is it a proven thing that CVS can corrupt a binary file if no merges >are tried and no CR/LF boundary rules are broken? In other words, if >I set -kb on a binary file and then do nothing to it but commit >updates and sometimes request an old revision, keeping my sandbox in >the OS in which it was checked out, could I ever get a bad result? I have personally kept binary files in CVS for many years. (Since before -kb was supported, but at that time all my systems were Unix boxes.) Since -kb and Windows interoperability were introduced, I have yet to hear a credible report about a binary file corruption that did not involve one of the following: - Some kind of hardware or network failure that corrupted the RCS file. - Someone did the initial checkin of the file without -kb set beforehand. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
Peter Connolly wrote: Too dificult to set up, I think Shouldn't cvs have a list of binary file types preinstalled in the cvswrappers ? I agree, it should. I second that ! I did 3 years ago. http://www.mail-archive.com/[EMAIL PROTECTED]/msg09098.html BTW - the cvswrappers file in the posting above has served me well. I have recently added openoffice files in the one I use currently. If anyone wants it, email me and I'll clean it up and post it. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >Doug Lee <[EMAIL PROTECTED]> writes: >> In other words, if I set -kb on a binary file and then do >> nothing to it but commit updates and sometimes request an >> old revision, keeping my sandbox in the OS in which it was >> checked out, could I ever get a bad result? >I have not ever noticed such a bad result. >I have noticed non-optimal checkout and commit >performance of binary versions of files when the >,v file starts to exceed a few hundred megabytes. >If the server is not properly configured with lots >of memory and temporary space, there can be problems >doing checkouts of lots of files of this type. 'Course, this holds true for multi-megabyte text files, too. But those are rare... >> This discussion of binary files has gone on a long time, >> but either I missed the answer to this, or I never saw it >> stated. If Greg Woods is reading this, you implied it once >> in a rather angry message. I welcome the proof, preferably >> without the anger. >The problem arises when two users concerntly modify a binary >file. After the first user commits, the second is stuck with >trying to figure out how to merge in the other set of changes >by hand with no help. There's no reason for CVS not to offer help, other than nobody's added it, yet. The only reason CVS doesn't help is because the only merge tool it knows is diff3, which is text-based. There's not a reason in the world why it couldn't be replaced with something more general, as was shown back in 2001. >Adrian Constantin <[EMAIL PROTECTED]> writes: >> > >Adrian Constantin writes: >> > >>=20 >> > >> Or maybe projects for Unix/Linux platforms >> > >> do not usualy have binary files, but I >> > >> don't really think so... >> >=20 >> > >CVS is a *source* control system; source >> > >files are rarely binary. >> >=20 >> > I disagree with this statement. Source files >> > are any files that cannot be reproduced >> > automatically. That is, changes must be made >> > to them manually using some editor, and that >> > editor need not be the likes of vi or emacs. >> > MS Word (or Frame Maker) documents, images of >> > various formats, and documents from various >> > design tools (e.g. GUI builders) are common >> > examples. >>=20 >> I tend to see this as a serious break in the >> cvs design . >Many people do. This is why I and others >consistently suggest that cvs may not be the best >source control system for general use. Yeah, well, sending such hapless people away is easier than fixing the tool. Demonstrating that such support could be added to CVS was done in less than eight man-hours; that's less effort than installing and training on a second tool. >> Today it is not relistic to assume serious >> projects with many developers involved will >> only contain text files.=20 >It is realistic to suggest that cvs is not >optimized for many kinds of 'serious' projects >with constraints of using binary files as a part >of the 'source' to be controlled. It is also realistic to suggest that it need not be this way. >svn, monotone, gnu arch and others have all arisen >more recently than cvs and try in various ways to >address the legacy problems that cvs continues to >have. And ignore. >> Also note that diff has the same problem, only >> for diff it might not be as acute as for cvs. >It is bacically the same problem given that diff >is being used internally to store deltas between >versions. Well, it's certainly possible to abstract out the RCS layer to provide better storage management for files that don't make small deltas. But the problem at hand is not due to the diff algorithm being used to generate the deltas; it's due to the diff and merge algorithm used at the UI level. >> Please note this problem is legacy since the >> days computer graphics were an advanced >> technology. When computers were text-based I >> can understand binary source files were a >> strange thing in any project. >Possibly. We have always had binary objects, but >many of them have source formats that are >compatible with the older text-based >representations. It is just that most folks choose >not to save the files in those formats for source >control. Possibly. But what's the point if the text-based representation is also unmergeable? >> I would have expected things to evolve. >Things have evolved. >> I think there are some binary diff algorithms... >Indeed. Consider svn which uses xdelta internally. >To be fair, CvsNt also has ways of dealing better >with binary formats than the cvshome version. >There is a hope that we can move toward merging >the feature sets between those two major varitions >of cvs over time, but it will likely take a bit of >time as no one is being funded full time to work >on just cvs development. Which is why it doesn't support capabilities that have already been demonstrated with alpha-quality code. As long as CVS development remains a hobby project, we can't exp
Re: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >> Doug Lee <[EMAIL PROTECTED]> writes: > >> > I think there are some binary diff algorithms... >> >> Indeed. Consider svn which uses xdelta internally. >> >> To be fair, CvsNt also has ways of dealing better >> with binary formats than the cvshome version. >> There is a hope that we can move toward merging >> the feature sets between those two major varitions >> of cvs over time, but it will likely take a bit of >> time as no one is being funded full time to work >> on just cvs development. > So I see there are many alternatives available, but > cvs has not changed. Looks like developers want to > offer their new products and not to support the > original cvs :( Very sad to find out about this > This is so strange and such a bad thing ... There are other reasons to abandon CVS, too. Having a real ability to rename a file is one. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adrian Constantin <[EMAIL PROTECTED]> writes: > > > Doug Lee <[EMAIL PROTECTED]> writes: > > > > > Is it a proven thing that CVS can corrupt a > > > binary file if no merges are tried and no > > > CR/LF boundary rules are broken? > > > > No. > I got it. > It will corrupt my files in the default > configuration after instalation, until I tell > it that .gif files are not text Correct. The present incarnation of cvs does not know that a particular file should be treated as a 'binary' just because the file name happens to match the pattern that some folks use for Graphical Interchange Format. I suppose we could collect the cvswrappers provided as a hint into the contrib directory... If someone wanted to hack in an automagical recognition system that could be enabled for binary file types, I suppose we could consider adding it. However, care would need to be taken that files that happened to be in I8N international character sets were handled properly too... > > svn, monotone, gnu arch and others have all arisen > > more recently than cvs and try in various ways to > > address the legacy problems that cvs continues to > > have. > > > > > > I think there are some binary diff algorithms... > > > > Indeed. Consider svn which uses xdelta internally. > > > > To be fair, CvsNt also has ways of dealing better > > with binary formats than the cvshome version. > > There is a hope that we can move toward merging > > the feature sets between those two major varitions > > of cvs over time, but it will likely take a bit of > > time as no one is being funded full time to work > > on just cvs development. > > So I see there are many alternatives > available, but cvs has not changed. No, cvs has changed a great deal. There was a time when it had significant problems with binary data. Now, once you tell it that it should treat it as binary, it mostly does the right thing (as has been mentioned, it probably should have the ability to plug in a series of merge programs other than diff3 to handle binary data better). It is also true that cvs lacks a full time advocate for change in this direction. Most of the advocates of major changes have left the cvs project to work on a redesign called subversion. The current cvs has many problems that are not yet addressed: - renaming files - versioning directories - dealing with symbolic links - better branching models - alternatives to diff3 for non-text files or structured text files (a la XML and HTML) where diff3 does not work well. - better access control models There are a lot of others as well, just look at the TODO file in the top-of-tree ccvs/TODO file some time. > Looks like developers want to offer their new > products and not to support the original cvs > :( Very sad to find out about this This is so > strange and such a bad thing ... It is not clear to me that incremental improvement to cvs will necessarily solve some of the major perceived flaws. I'd love to see more detailed plans on how to add improvements to cvs in a controlled way that lets everyone come along for the ride without lots of flag days taking place. However, that requires real work and commitment and a vision of what problems need to be solved. > > > > > > >The design itself does not needs litte > > >changes. cvs > > > > > >design can perfectly acomodate binary > > >sources. It just has to be done (or > > >implemented). > > > > Should I look forward to seeing your patches to > > help out on the project? They would be looked at > > with favor by all of your fellow cvs users. > > Well I write PHP now. I think there's a long way > from web pages to a serious public application Okay. > I hope I'll study xdelta in the near future It is an interesting topic. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAwrgY3x41pRYZE/gRArvxAJ9GIKVZ+E5SRUSswFlE+tdtnZXsUwCdErq+ C7A9YQeEwaDmJ5AC3wQ+Gwc= =zrsI -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
Hello, * On Sat, Jun 05, 2004 at 08:38:15PM -0700 Gianni Mariani wrote: * > Peter Connolly wrote: > > >>Too dificult to set up, I think Shouldn't cvs have a list of binary > >>file types preinstalled in the cvswrappers ? > > > >I agree, it should. > > > I second that ! I did 3 years ago. > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg09098.html I tend to disagree: It should not! Which extensions are binary files? Is .au a binary file? I know .au as (Sun?) audio file, but I've also seen a project where .au had the meaning of "additional user" or something like that, and was a text file. The same could be true for other extensions. What about .doc? .doc is not necessarily a Word file, especially not on old project. So, my conclusion is: Only the user is aware what type each file is. Checking in a text file with -kb (from a Windows machine) is something which many administrators do not like, either. If you have so much fear about binary files, why don't you put * -kb into your cvswrappers, and declare any text file explicitly? This way, you cannot miss the binary files. Best regards, Spiro. -- Spiro R. Trikaliotis I'm subscribed to the mailing lists I'm posting, http://www.trikaliotis.net/ so please refrain from Cc:ing me. Thank you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
Spiro Trikaliotis wrote: Hello, Hi ! ... If you have so much fear about binary files, why don't you put * -kb into your cvswrappers, and declare any text file explicitly? This way, you cannot miss the binary files. Actually, that was suggested 3 years ago as well. It turns out to be a very good one. However, while there are fewer standard file extensions that are text, many ad-hoc files (non-standard extensions) are almost allways text. Hence, it's easier to predict binary extensions that it is text extensions ! A suggestion 3 years ago was to run the "file" command on newly added files to determine it's format. That practice would solve your issue I presume. While you may be right about ".doc" or ".au" files, in practice, I have found that this has worked remarkably well. Over the course of 3 years, I have never had anyone complain about files that CVS broke. Almost all binary files added to CVS are - compressed source distros, prebuilt binaries, images, sound samples and open/win32 office files. Anyhow, it works for me, YMMV ! ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
Mark D. Baushke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adrian Constantin <[EMAIL PROTECTED]> writes: ... If someone wanted to hack in an automagical recognition system that could be enabled for binary file types, I suppose we could consider adding it. It already exists, it's called "file" ! $ file xx.cpp xx.cpp: ASCII C++ program text $ file dialog.gif dialog.gif: GIF image data, version 89a, 28 x 28 it appears that it returns a line with "text" if the file is considered text. I think that would be fairly trivial to add to cvs. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >* On Sat, Jun 05, 2004 at 08:38:15PM -0700 Gianni Mariani wrote: >* >> Peter Connolly wrote: >> >> >>Too dificult to set up, I think Shouldn't cvs have a list of binary >> >>file types preinstalled in the cvswrappers ? >> > >> >I agree, it should. >> > >> I second that ! I did 3 years ago. >> >> http://www.mail-archive.com/[EMAIL PROTECTED]/msg09098.html >I tend to disagree: It should not! >Which extensions are binary files? Is .au a binary file? I know .au as >(Sun?) audio file, but I've also seen a project where .au had the >meaning of "additional user" or something like that, and was a text >file. >The same could be true for other extensions. What about .doc? .doc is >not necessarily a Word file, especially not on old project. So, my >conclusion is: Only the user is aware what type each file is. Checking >in a text file with -kb (from a Windows machine) is something which many >administrators do not like, either. >If you have so much fear about binary files, why don't you put * -kb >into your cvswrappers, and declare any text file explicitly? This way, >you cannot miss the binary files. It's true that a general purpose file type identifier is not possible, it is possible to get arbitrarily close to 100% accuracy on a per-shop basis. Also, relying on file extensions alone is notoriously inaccurate. A mechanism like the Unix file(1) command that examines a file's content is much better. And then the configuration of it really needs to be in the CVS admin's face from the start. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gianni Mariani <[EMAIL PROTECTED]> writes: > Mark D. Baushke wrote: > > >-BEGIN PGP SIGNED MESSAGE- > >Hash: SHA1 > > > >Adrian Constantin <[EMAIL PROTECTED]> writes: > > > > > ... > > >If someone wanted to hack in an automagical > >recognition system that could be enabled for > >binary file types, I suppose we could consider > >adding it. > > > > It already exists, it's called "file" ! > > $ file xx.cpp > xx.cpp: ASCII C++ program text > $ file dialog.gif > dialog.gif: GIF image data, version 89a, 28 x 28 > > it appears that it returns a line with "text" if the file is > considered text. > > I think that would be fairly trivial to add to cvs. If someone wants to write a patch that will run the equivalent of 'file' on new source files to determine that the file needs -kb by default, that would be a useful extension to cvs client mode for both 'cvs add' and 'cvs import' cases. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAxBBS3x41pRYZE/gRApAxAKCl+1cE7B9BagquXV2y/nlOTWDGkQCgoI93 e9Hgsj3NpddLmyHuE3ct7Qw= =fgE5 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
Mark D. Baushke writes: > > If someone wants to write a patch that will run the > equivalent of 'file' on new source files to determine that > the file needs -kb by default, that would be a useful > extension to cvs client mode for both 'cvs add' and 'cvs > import' cases. Note carefully that Mark said the *equivalent* of file -- the 'file' command doesn't exist on many of the plaforms CVS runs on. -Larry Jones In short, open revolt and exile is the only hope for change? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
[ On Saturday, June 5, 2004 at 17:10:58 (-0700), Paul Sander wrote: ] > Subject: Re: CVS corrupts binary files ... > > Source files are any files that cannot > be reproduced automatically. Nope, that's wrong too. Source files are those files written and edited by humans. Source _code_ is human (and machine) readable. Intermediate files that might be "binary" in nature are not source. -- 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: CVS corrupts binary files ...
[ On Saturday, June 5, 2004 at 20:52:06 (-0700), Paul Sander wrote: ] > Subject: Re: CVS corrupts binary files ... > > Yeah, well, sending such hapless people away is easier > than fixing the tool. The tool is not "broken" -- I.e. there's nothing to fix! CVS is designed _only_ for tracking changes in human written text files. If you want to design (and implement) a new tool that does work well with non-text files then please do so. That'll give us yet another tool to recommend people use when they want to. > Demonstrating that such support > could be added to CVS was done in less than eight man-hours; Nope -- it's just not possible, as you should well know. This is a fundamental and purposeful design limitation in CVS. The entire concept of concurrent editing, which is central to the design and goals of CVS, is completely antithetical to managing binary files. Changing the design of CVS would make it some other "VS" that is not CVS any more. -- 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: CVS corrupts binary files ...
[ On Saturday, June 5, 2004 at 13:01:48 (-0700), Adrian Constantin wrote: ] > Subject: Re: CVS corrupts binary files ... > > I don't wanna merge binary files, and I'm not likely > to modify them in my module (project). I just want cvs > to carry them along with the sources Then your better tool is called a "directory" (i.e. outside of CVS) and you use it with a simple reference to it from within your build system. -- 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: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >> Source files are any files that cannot >> be reproduced automatically. >Nope, that's wrong too. >Source files are those files written and edited by humans. That's exactly what I said. Read that sentence again. >Source _code_ is human (and machine) readable. This is true, after a fashion. You still need a tool to read it. You seem to think that such a tool MUST be a text editor, but in fact such tools can edit data in other formats. >Intermediate files that might be "binary" in nature are not source. ^^ ^^^ That is true. Doesn't matter what format they're in. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
Oops, I omitted the Sept. 16 patch. Here it is at the bottom. --- Forwarded mail from [EMAIL PROTECTED] >--- Forwarded mail from [EMAIL PROTECTED] >[ On Saturday, June 5, 2004 at 20:52:06 (-0700), Paul Sander wrote: ] >> Subject: Re: CVS corrupts binary files ... >> >> Yeah, well, sending such hapless people away is easier >> than fixing the tool. >The tool is not "broken" -- I.e. there's nothing to fix! >CVS is designed _only_ for tracking changes in human written text files. So you say. I maintain that the diff and merge tools can be easily swapped out without making significant changes to the CVS design. With regard to merge tools, I proved my point with a patch posted to this forum on Sept. 16, 2001. I've included that patch at the bottom of this message. >If you want to design (and implement) a new tool that does work well >with non-text files then please do so. That'll give us yet another tool >to recommend people use when they want to. No need. See the patch below. >> Demonstrating that such support >> could be added to CVS was done in less than eight man-hours; >Nope -- it's just not possible, as you should well know. This is a >fundamental and purposeful design limitation in CVS. The entire concept >of concurrent editing, which is central to the design and goals of CVS, >is completely antithetical to managing binary files. I don't believe it was a "purposeful design limitation". CVS was initially designed before binary source formats were common, and it just didn't happen to include a plug-in method to support them. Keep in mind also that there's a difference between "binary files" and "mergeable files". The two concepts are in fact orthogonal; there are mergeable binary types (given a suitable tool), and there are unmergeable text types. CVS is bad at storing unmergeable files, no matter whether or not they're binary files. CVS can be easily modified to support mergeable binary types, as I've demonstrated, without significant impact to its design. >--- End of forwarded message from [EMAIL PROTECTED] --- End of forwarded message from [EMAIL PROTECTED] >From [EMAIL PROTECTED] Sun Sep 16 01:42:14 2001 X-Delivered: at request of sendmail on bugs Received: from zul.wakawaka.com (zul.wakawaka.com [192.148.188.5]) by bugs.wakawaka.com (8.8.8/8.8.5) with ESMTP id BAA11555 for <[EMAIL PROTECTED]>; Sun, 16 Sep 2001 01:42:14 -0700 (PDT) Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by zul.wakawaka.com (8.8.8/8.8.5) with ESMTP id BAA07411 for <[EMAIL PROTECTED]>; Sun, 16 Sep 2001 01:46:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.22 #1 (Debian)) id 15iXGh-0007cp-00; Sun, 16 Sep 2001 04:27:11 -0400 Received: from zul.wakawaka.com ([205.219.70.4]) by fencepost.gnu.org with esmtp (Exim 3.22 #1 (Debian)) id 15iXEG-0007Se-00 for <[EMAIL PROTECTED]>; Sun, 16 Sep 2001 04:24:40 -0400 Received: from bugs.wakawaka.com (bugs.wakawaka.com [192.148.188.8]) by zul.wakawaka.com (8.8.8/8.8.5) with ESMTP id BAA07400 for <[EMAIL PROTECTED]>; Sun, 16 Sep 2001 01:24:38 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by bugs.wakawaka.com (8.8.8/8.8.5) id BAA11542 for [EMAIL PROTECTED]; Sun, 16 Sep 2001 01:20:53 -0700 (PDT) Message-Id: <[EMAIL PROTECTED]> From: [EMAIL PROTECTED] In-Reply-To: <[EMAIL PROTECTED]> X-Mailer: Mail User's Shell (7.2.6 beta(4)+dynamic 03/19/98) To: [EMAIL PROTECTED] Subject: Demo of extensible merge (was Re: giving up CVS) Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <http://mail.gnu.org/mailman/listinfo/info-cvs>, <mailto:[EMAIL PROTECTED]> List-Id: Announcements and discussions for the CVS version control system List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/info-cvs>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://mail.gnu.org/pipermail/info-cvs/> Date: Sun, 16 Sep 2001 01:20:52 -0700 Status: OR >--- Forwarded mail from Greg Woods: >> CVS is perfectly capable of supporting even >> unmergable file types with only minor changes to its logic, specifically >> by adding an extensible mechanism to select the correct merge tool for the >> data type at hand. >So you seem to claim. So far though you've only proposed the most >superficial of functional specifications, and certainly there's been no >appearance of running code to cloud the issue I call your bluff and raise
Re: CVS corrupts binary files ...
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > [ On Saturday, June 5, 2004 at 13:01:48 (-0700), > Adrian Constantin wrote: ] > > Subject: Re: CVS corrupts binary files ... > > > > I don't wanna merge binary files, > > Then your better tool is called a "directory" (i.e. > outside of CVS) > -- You can't be serious about this... My module is a web site. The directory structure is already created, with a several directories for images. They have their place on the web server, with already done aliases. Even if I don't edit binary files like source code, sometimes I may add or remove a few images ro/from my site. And in the future when the site is ready I might want to redesign it and change image files. If images are outside of cvs, they won't be delivered by cvs checkout. This is not exactly recomanded. And I think my binaries are conceptualy part of the project like source file are. Now maybe developing a web site with cvs is not very common. What if I have a real project with some custom libraries, ordered especially for the project. Theese are also binaries not likely to be merged or changed, but I don't see an outside directory as a good place for them Adrian Constantin And I don't wanna miss a thing __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Saturday, June 5, 2004 at 20:52:06 (-0700), Paul Sander wrote: ] >> Subject: Re: CVS corrupts binary files ... >> >> Yeah, well, sending such hapless people away is easier >> than fixing the tool. >The tool is not "broken" -- I.e. there's nothing to fix! >CVS is designed _only_ for tracking changes in human written text files. So you say. I maintain that the diff and merge tools can be easily swapped out without making significant changes to the CVS design. With regard to merge tools, I proved my point with a patch posted to this forum on Sept. 16, 2001. I've included that patch at the bottom of this message. >If you want to design (and implement) a new tool that does work well >with non-text files then please do so. That'll give us yet another tool >to recommend people use when they want to. No need. See the patch below. >> Demonstrating that such support >> could be added to CVS was done in less than eight man-hours; >Nope -- it's just not possible, as you should well know. This is a >fundamental and purposeful design limitation in CVS. The entire concept >of concurrent editing, which is central to the design and goals of CVS, >is completely antithetical to managing binary files. I don't believe it was a "purposeful design limitation". CVS was initially designed before binary source formats were common, and it just didn't happen to include a plug-in method to support them. Keep in mind also that there's a difference between "binary files" and "mergeable files". The two concepts are in fact orthogonal; there are mergeable binary types (given a suitable tool), and there are unmergeable text types. CVS is bad at storing unmergeable files, no matter whether or not they're binary files. CVS can be easily modified to support mergeable binary types, as I've demonstrated, without significant impact to its design. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Folks, Greg writes: > CVS is designed _only_ for tracking changes in > human written text files. Paul writes: > Keep in mind also that there's a difference > between "binary files" and "mergeable files". > The two concepts are in fact orthogonal; there > are mergeable binary types (given a suitable > tool), and there are unmergeable text types. CVS > is bad at storing unmergeable files, no matter > whether or not they're binary files. CVS can be > easily modified to support mergeable binary > types, as I've demonstrated, without significant > impact to its design. In my view, CVS was designed to add a model of concurrent modification and automatic merges on top of the previously existing Revision Control System representation of files. The removal of exclusive locking for changes is the fundamental reason that CVS exists. It may be that the diff3 algorithm is not always the best one suited to do such mergers. For example, using a UTF16 character set in a file for example may prove to be difficult to merge even if the text in the file is only a "simple" Chinese representation. Perhaps something like the xcin project will eventually provide a diff3 for use in this case. It may be desirable to mark UTF8 or UTF16 files as being 'binary' in order to preserve the text more exactly across operating systems that are not (yet) friendly to such text. For this reason, I take Paul's side on the issue of the orthogonal nature of the discussion of files that may or may not be "merged" using automatic tooling of some sort. I also share Greg's bias that using CVS to save arbitrary binary data and/or derived objects is not something that is a core competence of CVS. For myself, I have no objection to a few small icons being checked into a repository that will also be holding sources that use them (of course, I would usually favor them being convereted into a text representation such as xbm format or the like). I have seen where using very large binary objects can cause problems for both users and administrators. I have also seen problems where folks checkin derived objects such as PostScript files that are pure text files, but normally are not merged effectively by a diff3 program during a normal 'cvs update' of a file. I believe that adding flexibility to CVS as to what program should be used in place of diff3 for doing a merge operation is desirable. That said, I do not know the correct approach to take for allowing the cvs admin or user do such a merge with a non-diff3 tool. Some such tools are (by their nature) interactive and this does not seem to be a good fit with the CVS methodology. Some such programs may only be available on client machines while others would potentially be available on the server. I typically favor that such programs would be consdiered to be present on the server and NOT on the client. The exact semantics and rules under which a substitution for a different program than diff3 could be used for a merge operation need to be carefully considered before we jump into a change. I suspect that we would need to add a filetype recognizer into cvs as a preliminary step to help to classify the type of a file that is to be merged (or added or imported for that matter) in order to know which of the potentially large number of three-way merge programs and scripts should be used or considered for use during a given cvs merge operation. I do not consider filetypes driven by the name of a file to be useful in such deliberations. If anyone has any suggestions or other patches for this kind of feature, I would be interested in hearing about them. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAxknf3x41pRYZE/gRAsQtAJ0bBnvfNdF+2aPUzb/fr6qEuAFJcQCgluGR 7HTwfoQL1NFRQeQGeLosGP8= =9laK -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED]
>Greg writes:
>> CVS is designed _only_ for tracking changes in
>> human written text files.
>Paul writes:
>> Keep in mind also that there's a difference
>> between "binary files" and "mergeable files".
>> The two concepts are in fact orthogonal; there
>> are mergeable binary types (given a suitable
>> tool), and there are unmergeable text types. CVS
>> is bad at storing unmergeable files, no matter
>> whether or not they're binary files. CVS can be
>> easily modified to support mergeable binary
>> types, as I've demonstrated, without significant
>> impact to its design.
>In my view, CVS was designed to add a model of
>concurrent modification and automatic merges on
>top of the previously existing Revision Control
>System representation of files. The removal of
>exclusive locking for changes is the fundamental
>reason that CVS exists.
>It may be that the diff3 algorithm is not always
>the best one suited to do such mergers.=20
Well said.
However, I'm not 100% convinced that "automatic merges"
is a prerequisite of the concurrency model. I see no
reason why a command like "cvs update" could not spawn
a graphical merge tool (even for C source code, for
example). However, such actions, should they stall,
must not stop others from doing their own merges or
from committing new changes.
>For example, using a UTF16 character set in a file
>for example may prove to be difficult to merge
>even if the text in the file is only a "simple"
>Chinese representation. Perhaps something like
>the xcin project will eventually provide a diff3
>for use in this case.
>It may be desirable to mark UTF8 or UTF16 files as
>being 'binary' in order to preserve the text more
>exactly across operating systems that are not
>(yet) friendly to such text.
>For this reason, I take Paul's side on the issue
>of the orthogonal nature of the discussion of
>files that may or may not be "merged" using
>automatic tooling of some sort.
Thanks! :-)
>I also share Greg's bias that using CVS to save
>arbitrary binary data and/or derived objects is
>not something that is a core competence of CVS.
Saving derived objects is definitely not a best practice
in SCM, at least not in the source control system. Whether
or not arbitrary (or opaque) binary data should or should
not be stored in CVS is a sticky question, because it may
very well be source code (i.e. data that can be created or
modified only by human intervention), in which case I
believe it should be stored in the source control system.
For merges, opaque data must be handled appropriately. One
way is to take Greg's approach and boot it out completely.
I believe a better way is to apply a simple selection tool
that takes the place of a merge tool. (After all, any data
type is mergeable if you can swap out the entire contents of
a file in one chunk, right? :-)
>For myself, I have no objection to a few small
>icons being checked into a repository that will
>also be holding sources that use them (of course,
>I would usually favor them being convereted into a
>text representation such as xbm format or the
>like). I have seen where using very large binary
>objects can cause problems for both users and
>administrators.
It's important to note that xbm format is also an unmergeable
data type, at least with diff3, even if such files do not
contain non-printable ASCII characters. The reason is that
it's hard to edit an image without seeing it as an image.
I agree about storing large binary files in CVS; it would be nice
if there were multiple storage managers to choose from, depending
on their suitability to the data at hand. But given that RCS
works (though admittedly not necessarily well) in all cases, it's
good enough (for 95%+ of the files thrown at it) that I don't see
a reason to change at this moment. ('Course, I'd be happy to
participate in a separate discussion about creating an abstraction
layer over RCS and plugging in other storage managers... :-)
>I have also seen problems where folks checkin
>derived objects such as PostScript files that are
>pure text files, but normally are not merged
>effectively by a diff3 program during a normal
>'cvs update' of a file.
>I believe that adding flexibility to CVS as to
>what program should be used in place of diff3 for
>doing a merge operation is desirable.
>That said, I do not know the correct approach to
>take for allowing the cvs admin or user do such a
>merge with a non-diff3 tool. Some such tools are
>(by their nature) interactive and this does not
>seem to be a good fit with the CVS methodology.
I believe that the data type should be stored in a
newphrase in the admin section of the RCS file.
The bad thing about that is that if the RCS file is
recycled with a new data type, or if it contains
different data types on different branches, there
is no correct value for the newphrase.
Others have stated that the data type should be
stored with each version of the file. That way
you ca
RE: CVS corrupts binary files ...
Greg A. Woods wrote: > [ On Saturday, June 5, 2004 at 13:01:48 (-0700), Adrian > Constantin wrote: ] > > Subject: Re: CVS corrupts binary files ... > > > > I don't wanna merge binary files, and I'm not likely to > modify them in > > my module (project). I just want cvs to carry them along with the > > sources > > Then your better tool is called a "directory" (i.e. outside > of CVS) and you use it with a simple reference to it from > within your build system. Hehehehe... good one. Hang on - there was no smiley there. Oh my - you were serious! Let's not throw the baby out with the bathwater, shall we? Granted, CVS was not *originally* designed to handle binary files. Granted, CVS does not handle binary files as well as it handles mergeable text files. But even with CVS's handicaps and limitations WRT binary, CVS is still orders of magnitude better than manually maintaining versions of files in a directory. Embrace change, Greg. These days, binary files are considered "source". CVS needs to move with the times, or step aside for another VM system. -- Jim ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
I have a website in CVS, with a good number of .jpg files. I don't have any problems with the binary files. I usually add or remove the binary files, rarely change them. I guess I missed the beginning of this thread, but what's the problem that you're having? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Constantin Sent: Tuesday, June 08, 2004 6:01 PM To: CVS-II Discussion Mailing List Subject: Re: CVS corrupts binary files ... --- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > [ On Saturday, June 5, 2004 at 13:01:48 (-0700), > Adrian Constantin wrote: ] > > Subject: Re: CVS corrupts binary files ... > > > > I don't wanna merge binary files, > > Then your better tool is called a "directory" (i.e. > outside of CVS) > -- You can't be serious about this... My module is a web site. The directory structure is already created, with a several directories for images. They have their place on the web server, with already done aliases. Even if I don't edit binary files like source code, sometimes I may add or remove a few images ro/from my site. And in the future when the site is ready I might want to redesign it and change image files. If images are outside of cvs, they won't be delivered by cvs checkout. This is not exactly recomanded. And I think my binaries are conceptualy part of the project like source file are. Now maybe developing a web site with cvs is not very common. What if I have a real project with some custom libraries, ordered especially for the project. Theese are also binaries not likely to be merged or changed, but I don't see an outside directory as a good place for them Adrian Constantin And I don't wanna miss a thing __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
On Tue, 2004-06-08 at 17:42, Paul Sander wrote: > Keep in mind also that there's a difference between "binary files" and > "mergeable files". That's a neat point. Most of my Java projects use 3rd party jar files, which are compressed tar balls, more or less. And I certainly don't want to try to merge foolib-0.1.jar with foolib-0.2.jar when a new version comes out; I just want to put it in CVS so that it gets tagged and exported and so forth. So it's not mergeable, but it is binary. Or something. Yours, Tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
[ On Tuesday, June 8, 2004 at 15:01:10 (-0700), Adrian Constantin wrote: ] > Subject: Re: CVS corrupts binary files ... > > > --- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > > [ On Saturday, June 5, 2004 at 13:01:48 (-0700), > > Adrian Constantin wrote: ] > > > Subject: Re: CVS corrupts binary files ... > > > > > > I don't wanna merge binary files, > > > > Then your better tool is called a "directory" (i.e. > > outside of CVS) > > -- > > You can't be serious about this... Yes, I was, and am, absolutely serious about that. CVS is _not_ a build system. CVS is _not_ a complete software configuration system. It doesn't matter what you're managing (C source, HTML source, nroff or TeX source, etc.), CVS is only one of the tools you must use to handle your source files. -- 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: CVS corrupts binary files ...
[ On Tuesday, June 8, 2004 at 16:21:03 (-0700), Mark D. Baushke wrote: ] > Subject: Re: CVS corrupts binary files ... > > In my view, CVS was designed to add a model of > concurrent modification and automatic merges on > top of the previously existing Revision Control > System representation of files. The removal of > exclusive locking for changes is the fundamental > reason that CVS exists. Yes, that's true. > It may be that the diff3 algorithm is not always > the best one suited to do such mergers. That may be true, but the use of the traditional diff and diff3 algorithms for detecting and merging changes in the managed files is a direct concequence of the fact CVS is built on top of RCS and RCS has no alternative to using, and no _real_ way to specify any alternative, to these algorithms (at least not without breaking RCS compatability). > I believe that adding flexibility to CVS as to > what program should be used in place of diff3 for > doing a merge operation is desirable. It might be desirable but it's not really possible without giving up on the use of RCS in the back-end -- or at least without giving up on backwards compatabiltiy with other RCS tools. It's not really necessary either. There are lots of alternatives. People just need to learn to use the right tool for the job and to quit being so bloody narrow minded when it comes to learning about new tools. -- 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: CVS corrupts binary files ...
[ On Wednesday, June 9, 2004 at 09:15:24 (-0400), Jim.Hyslop wrote: ] > Subject: RE: CVS corrupts binary files ... > > Let's not throw the baby out with the bathwater, shall we? Granted, CVS was > not *originally* designed to handle binary files. Granted, CVS does not > handle binary files as well as it handles mergeable text files. But even > with CVS's handicaps and limitations WRT binary, CVS is still orders of > magnitude better than manually maintaining versions of files in a directory. How do you figure that? A plain old directory is infinitely better at managing static content, binary or not, than _any_ versioning tool. Anything over and above a plain old directory _only_ adds unnecessary layers of complexity. Haven't you learned yet that you'll do a lot better if you choose the best tools for each job rather than hitting everything on the head with your damn hammer!?!?!?!?! -- 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: CVS corrupts binary files ...
[ On Wednesday, June 9, 2004 at 09:35:37 (-0400), Tom Copeland wrote: ] > Subject: Re: CVS corrupts binary files ... > > On Tue, 2004-06-08 at 17:42, Paul Sander wrote: > > Keep in mind also that there's a difference between "binary files" and > > "mergeable files". > > That's a neat point. Well, it's kind of a pointless point, neat or not. The only thing that's really important w.r.t. whether CVS can manage the file reliabily and without headache is whether diff & patch can reliably copy changes from one version of the file to another _and_ that any conflicts in those copies can be detected and easily resolved by hand. > Most of my Java projects use 3rd party jar files, > which are compressed tar balls, more or less. And I certainly don't > want to try to merge foolib-0.1.jar with foolib-0.2.jar when a new > version comes out; I just want to put it in CVS so that it gets tagged > and exported and so forth. No, you REALLY DO NOT want (or need) to do that. What a waste. What you should do is treat the foolib product files for what they are and to install them as products on your build machines in directories named after their complete version-specific identifiers. Then you need only program your build system to refer to the appropriate directory for the appropriate components and if your build system is anywhere half decent you'll simply check in the build system configuration source file(s) and tag them. Once you've done that then you can check out any release of your source and type "make" and the right components will be combined with your sources to create your final product. CVS is _not_ a build system. CVS is _not_ a complete configuration management system. Please learn to use the right tool for the job -- 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: CVS corrupts binary files ...
On Thu, 2004-06-17 at 16:12, Greg A. Woods wrote: > > Most of my Java projects use 3rd party jar files, > > which are compressed tar balls, more or less. And I certainly don't > > want to try to merge foolib-0.1.jar with foolib-0.2.jar when a new > > version comes out; I just want to put it in CVS so that it gets tagged > > and exported and so forth. > > No, you REALLY DO NOT want (or need) to do that. What a waste. > > What you should do is treat the foolib product files for what they are > and to install them as products on your build machines in directories > named after their complete version-specific identifiers. Hm. Why not simply check these jar files into the repository where they can be tagged/branched/exported and so forth? Why should every programmer on my team need to get all the versions of each jar file laid out on his machine when he could just do a "cvs up" to get the current stuff for his branch? > Then you need only program your build system to refer to the appropriate > directory for the appropriate components Why bother with that? Just put the jar files in myproject/lib and point the Ant script to them. And if we've got a FAR_OUT branch that uses foolib-0.3.jar, that jar file is in that branch and the Ant build.xml there points to it. > and if your build system is > anywhere half decent you'll simply check in the build system > configuration source file(s) and tag them. Yup, makes sense. > Once you've done that then > you can check out any release of your source and type "make" and the > right components will be combined with your sources to create your final > product. Yup, that's what's happening now. Maybe we're converging... Yours, Tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Tuesday, June 8, 2004 at 16:21:03 (-0700), Mark D. Baushke wrote: ] >> Subject: Re: CVS corrupts binary files ... >> It may be that the diff3 algorithm is not always >> the best one suited to do such mergers. >That may be true, but the use of the traditional diff and diff3 >algorithms for detecting and merging changes in the managed files is a >direct concequence of the fact CVS is built on top of RCS and RCS has no >alternative to using, and no _real_ way to specify any alternative, to >these algorithms (at least not without breaking RCS compatability). Although the earliest releases of CVS used the rcsmerge program to perform merges, I think you'll agree that the following are equivalent: rcsmerge -pversion1 -pversion2 file versus: co -pversion1 > temp1 co -pversion2 > temp2 diff3 -E -am file temp1 temp2 Current releases of CVS do the latter. (Don't believe me? Look at the function named RCS_merge in the rcscmds.c source file.) It's a simple matter to replace the invocation of diff3 with a different tool. Given this, statements like the following do nothing but spread FUD. They are flatly false, and you would do the world a big favor if you would stop writing them. >It might be desirable but it's not really possible without giving up on >the use of RCS in the back-end -- or at least without giving up on >backwards compatabiltiy with other RCS tools. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Wednesday, June 9, 2004 at 09:15:24 (-0400), Jim.Hyslop wrote: ] >> Subject: RE: CVS corrupts binary files ... >> >> Let's not throw the baby out with the bathwater, shall we? Granted, CVS was >> not *originally* designed to handle binary files. Granted, CVS does not >> handle binary files as well as it handles mergeable text files. But even >> with CVS's handicaps and limitations WRT binary, CVS is still orders of >> magnitude better than manually maintaining versions of files in a directory. >How do you figure that? A plain old directory is infinitely better at >managing static content, binary or not, than _any_ versioning tool. >Anything over and above a plain old directory _only_ adds unnecessary >layers of complexity. I've done revision control by backup, and I've done revision control by naming convention. Both have proven to be disasters. Introducing uncontrolled sources into your process is not the answer. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
At 4:02 PM -0400 6/17/04, Greg A. Woods wrote: People just need to learn to use the right tool for the job and to quit being so bloody narrow minded when it comes to learning about new tools. First, I do not claim to have anything resembling expert (or even mediocre) knowledge in the usage of CVS - but I do use it for simple tasks. I have no problem using/learning new tools. I'd personally love to be able to use VooDoo for version control, but there are two problems: 1. It's not free 2. There is no standalone client for it 3. There is no windows version #1 is, of course, a very compelling reason to use any piece of software that works. Can you point to an alternative to CVS that is also free? There is one thing that I simply don't understand with respect to CVS and Binary Files. Why would it not work well to use a CVS Wrapper to binhex (uuencode, etc.) a binary file and then essentially have CVS to only see your file as a text file? It's pretty obvious to everyone that merge features of CVS will not work with binary files and should not be attempted. However, diff & patch should work on a binhex'd file. Of course, the storage would be rather inefficient - probably requiring the storage of the entire file on every checkinbut then, disk space is cheap these days. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >At 4:02 PM -0400 6/17/04, Greg A. Woods wrote: >I have no problem using/learning new tools. I'd personally love to be >able to use VooDoo for version control, but there are two problems: >1. It's not free >2. There is no standalone client for it >3. There is no windows version >#1 is, of course, a very compelling reason to use any piece of >software that works. Can you point to an alternative to CVS that is >also free? Here are four: RCS, Aegis, Monotone, OpenCM. >There is one thing that I simply don't understand with respect to CVS >and Binary Files. >Why would it not work well to use a CVS Wrapper to binhex (uuencode, >etc.) a binary file and then essentially have CVS to only see your >file as a text file? The key is that there's a distinction between text files and mergeable files. Programs like binhex and uuencode produce text files, but they're not mergeable. CVS works best on files that are both ASCII and mergeable. CVS could be made to work on files that mergeable but not ASCII. Once that is done, non-mergeable files could be made to look like mergeable files by supplying a diff tool that works like cmp, and merge tool that works like cp; but you must remember that the results of using such tools are not impressive. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
Greg A. Woods wrote: > [ On Wednesday, June 9, 2004 at 09:15:24 (-0400), Jim.Hyslop wrote: ] > > Subject: RE: CVS corrupts binary files ... > > > > Let's not throw the baby out with the bathwater, shall we? Granted, > > CVS was not *originally* designed to handle binary files. > Granted, CVS > > does not handle binary files as well as it handles mergeable text > > files. But even with CVS's handicaps and limitations WRT > binary, CVS > > is still orders of magnitude better than manually > maintaining versions of files in a directory. > > How do you figure that? A plain old directory is infinitely > better at managing static content, binary or not, than _any_ > versioning tool. Ah, I think I've spotted the root of this disagreement. I was not talking about static information, but binary information that can, and does, change. For static information, yes, CVS is overkill. But if it changes, then I stand by my earlier statement: CVS is orders of magnitude better than manual versioning with directories. -- 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 corrupts binary files ...
At 1:40 PM -0700 6/17/04, Paul Sander wrote: >Why would it not work well to use a CVS Wrapper to binhex (uuencode, etc.) a binary file and then essentially have CVS to only see your file as a text file? The key is that there's a distinction between text files and mergeable files. Programs like binhex and uuencode produce text files, but they're not mergeable. Well, as I stated...simply avoid the merge features on files that are not mergeable. It's not terribly difficult to determine that a file should not be merged after staring at a binhex'd file for <= 1 second, assuming one could not determine from the name of the file that merge functions should not be used. CVS works best on files that are both ASCII and mergeable. So, one is required to use the merge functions of CVS? They cannot be avoided? If they can be avoided, this point seems irrelevant. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
[ On Thursday, June 17, 2004 at 16:25:02 (-0400), Tom Copeland wrote: ] > Subject: Re: CVS corrupts binary files ... > > Hm. Why not simply check these jar files into the repository where they > can be tagged/branched/exported and so forth? Why should every > programmer on my team need to get all the versions of each jar file laid > out on his machine when he could just do a "cvs up" to get the current > stuff for his branch? Don't you have a build system? (apparently you do going by your later comments) Can't it do all those things for you? Let me repeat: CVS is _not_ a build system. Just because you can use CVS to update version-controlled files from some central repository doesn't mean you should try to use CVS to copy all types of files from all kinds of repositories. If you have many and diverse build machines then put your static (i.e. non-changing) components on a central machine in a public directory and have your build system invoke the appropriate tool to copy them into the build environment as necessary. If you do that, and if the way you reference those components includes information about their version numbers (e.g. in the name of the directory they're "installed" in), and if your build system is configured using normal source files (e.g. text makefiles) that you commit to your CVS repository, then CVS will track which version of which component is needed for every release. -- 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: CVS corrupts binary files ...
[ On Thursday, June 17, 2004 at 13:06:44 (-0700), Paul Sander wrote: ] > Subject: Re: CVS corrupts binary files ... > > Current releases of CVS do the latter. (Don't believe me? Look at > the function named RCS_merge in the rcscmds.c source file.) It's a > simple matter to replace the invocation of diff3 with a different tool. Huh!?!?!? Since when does the phrase "diff and diff3 algorithms" identify any particular program that might implement those algorithms? Paul, _you_ are the one spreading FUD here. In case you have forgotten I am intimately familiar with exactly how the GNU diffutils code and the GNU patch code is integrated into the CVS source. -- 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: CVS corrupts binary files ...
[ On Thursday, June 17, 2004 at 13:09:09 (-0700), Paul Sander wrote: ] > Subject: RE: CVS corrupts binary files ... > > I've done revision control by backup, and I've done revision control > by naming convention. Both have proven to be disasters. Obviously you tried to use these tehniques in isolation. > Introducing uncontrolled sources into your process is not the answer. Obviously you missed (or conveniently ignored) the step where the build system's configuration source file(s) are checked into the CVS repository and thus becomes a very much _controlled_ part of the SCM process. -- 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: CVS corrupts binary files ...
[ On Thursday, June 17, 2004 at 17:03:34 (-0400), Eric Gorr wrote: ] > Subject: Re: CVS corrupts binary files ... > > #1 is, of course, a very compelling reason to use any piece of > software that works. Can you point to an alternative to CVS that is > also free? Check the various FAQs related to software configuration management and Google for relevant phrases. There are quite a few such systems -- which you might choose will depend on many factors only you can know! ;-) > There is one thing that I simply don't understand with respect to CVS > and Binary Files. > > Why would it not work well to use a CVS Wrapper to binhex (uuencode, > etc.) a binary file and then essentially have CVS to only see your > file as a text file? Well, if you think you can easily resolve a conflict from a merge of a binary file that's been encoded into some plain-text form, then I'll bet you can also read and debug good old-fashioned hex dumps in your sleep too! :-) > It's pretty obvious to everyone that merge features of CVS will not > work with binary files and should not be attempted. Precisely! :-) > However, diff & patch should work on a binhex'd file. No, they won't -- at least they won't unless you can properly decode, successfully merge bits of, and then properly recode them into a consistent hex dump again. I.e. keep in mind what the "C" in CVS really means. Even though it comes first in the name it's really _very_ central to the design of the system. If you don't need/want to use a concurrent versioning system then please don't try to use CVS, even if it is free, and even if it is the kind of client/server system you're looking for. Just because you have two nails and a screw doesn't mean a hammer is the only tool you'll need. You might even be able to eventually hammer the nails in with the handle of your screwdriver, but I'm sure you'll agree it's still not the right tool for the job either. People do indeed manage to get by with just a screwdriver sometimes, and they don't always hurt themselves or damage their screwdriver when they hammer in nails with it either, but that still doesn't mean anyone really should be advising them that they're doing the right thing. They do that sort of thing on the Red Green show, but they get away with it because their goal is to be funny, not to build software, etc. -- 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: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >At 1:40 PM -0700 6/17/04, Paul Sander wrote: >> >Why would it not work well to use a CVS Wrapper to binhex (uuencode, >>>etc.) a binary file and then essentially have CVS to only see your >>>file as a text file? >> >>The key is that there's a distinction between text files and mergeable >>files. Programs like binhex and uuencode produce text files, but they're >>not mergeable. >Well, as I stated...simply avoid the merge features on files that are >not mergeable. It's not terribly difficult to determine that a file >should not be merged after staring at a binhex'd file for <= 1 >second, assuming one could not determine from the name of the file >that merge functions should not be used. >>CVS works best on files that are both ASCII and mergeable. >So, one is required to use the merge functions of CVS? They cannot be avoided? >If they can be avoided, this point seems irrelevant. Unfortunately, merging is a central aspect of the concurrent paradigm. If you avoid merging, you abandon the concurrent model. Such a thing can be done, but it's not a natural usage model for CVS. On the other hand, if CVS embraced additional merge algorithms (that could be considered degenerate cases, like full content swapping) then CVS might well work for unmergeable data types. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Thursday, June 17, 2004 at 13:09:09 (-0700), Paul Sander wrote: ] >> Subject: RE: CVS corrupts binary files ... >> >> I've done revision control by backup, and I've done revision control >> by naming convention. Both have proven to be disasters. >Obviously you tried to use these tehniques in isolation. >> Introducing uncontrolled sources into your process is not the answer. >Obviously you missed (or conveniently ignored) the step where the build >system's configuration source file(s) are checked into the CVS repository >and thus becomes a very much _controlled_ part of the SCM process. Nope, I got it. The thing is, you can control pointers (e.g. makefiles containing references to files stored in a library somewhere) all you want, but that buys you nothing unless the targets of the pointers are also tightly controlled. Just grabbing stuff and throwing it in a directory, maybe giving it a unique name, simply isn't enough. You still need to prevent uncontrolled changes from being introduced, reproducing it if something fails, repeating the configuration when upgrading, and all the other stuff that a full CM system does. That means the stuff that you can't create from other sources must be kept under some form of source control, and you need a build procedure to make it useful, among other things. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
Responding above rather than below largely because my comments are
general thoughts on the whole discussion...
There is wisdom in choosing the right tool for a job. There is also
wisdom in making the best use of the tools you already know and have.
Both can be taken to unpleasant extremes. I believe both extremes can
be "wrong" (from a functional standpoint).
The fact that CVS was designed for mergeable data means it should be
good at that. It does not mean it absolutely cannot serve further
useful purposes. Those who want to use CVS for further purposes would
be well advised to know just what CVS is and is not capable of doing
(note this is not the same as what it was originally designed for, but
rather is what it happens to be able to do reliably).
So for the job of managing versions of mergeable files, CVS bills
itself as ready, and it should do well. For the job of managing
unmergeable files, it sounds to me like it can, regardless of original
intent, as long as you don't go trying impossible stuff. For the job
of managing distribution of file sets among workstations (which may be
on a LAN or across a VPN connection or an ssh connection or whatever
but which do not necessarily have access to a central file location),
I find CVS reasonable.
And may I humbly suggest that, for the job of pursuading the unwashed
masses such as myself of the pitfalls and folly of using CVS for
further purposes than concurrent versioning, information might be a
better tool than inflamation. :-) (Specifically to Greg: The latest
post I saw from you, the one more precisely describing how one might
lay out binary files in directories, manage them with a
version-controlled config file, etc., has made me think more about
this than any other post to date.)
On Thu, Jun 17, 2004 at 06:16:32PM -0400, Greg A. Woods wrote:
> [ On Thursday, June 17, 2004 at 16:25:02 (-0400), Tom Copeland wrote: ]
> > Subject: Re: CVS corrupts binary files ...
> >
> > Hm. Why not simply check these jar files into the repository where they
> > can be tagged/branched/exported and so forth? Why should every
> > programmer on my team need to get all the versions of each jar file laid
> > out on his machine when he could just do a "cvs up" to get the current
> > stuff for his branch?
>
> Don't you have a build system? (apparently you do going by your later
> comments)
>
> Can't it do all those things for you?
>
> Let me repeat: CVS is _not_ a build system.
>
> Just because you can use CVS to update version-controlled files from
> some central repository doesn't mean you should try to use CVS to copy
> all types of files from all kinds of repositories.
>
> If you have many and diverse build machines then put your static
> (i.e. non-changing) components on a central machine in a public
> directory and have your build system invoke the appropriate tool to copy
> them into the build environment as necessary. If you do that, and if
> the way you reference those components includes information about their
> version numbers (e.g. in the name of the directory they're "installed"
> in), and if your build system is configured using normal source files
> (e.g. text makefiles) that you commit to your CVS repository, then CVS
> will track which version of which component is needed for every release.
>
> --
> 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
--
Doug Lee [EMAIL PROTECTED]http://www.dlee.org
Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com
"Our chief want in life is somebody who will make us do what
we can. {Ralph Waldo Emerson}
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Gorr <[EMAIL PROTECTED]> writes: > Can you point to an alternative to CVS that is also free? Certainly. There are a number of such programs. Here are the Open Source and/or Free Software Source or configuration management programs: Aegis- http://aegis.sourceforge.net/ cscvs- http://wiki.gnuarch.org/moin.cgi/cscvs CVS - http://www.cvshome.org/ CVSNT- http://www.cvsnt.org/ Darcs- http://abridgegame.org/darcs/ FTPVCS - http://www.ftpvcs.org/ FreeVCS - http://www.thensle.de/index.html GNU Arch - http://wiki.gnuarch.org/ GNU CSSC - http://cssc.sourceforge.net/index.shtml JRMS - http://jrms.sourceforge.net/ Katie- http://www.netcraft.com.au/geoffrey/katie/ MetaCVS - http://users.footprints.net/~kaz/mcvs.html Monotone - http://www.venge.net/monotone/ OpenCM - http://www.opencm.org/ PRCS - http://prcs.sourceforge.net/ RCS - http://www.cs.purdue.edu/homes/trinkle/RCS/ SourceJammer - http://www.sourcejammer.org/ Stellation - http://www.eclipse.org/stellation/ Subversion - http://subversion.tigris.org/ Superversion - http://www.sourcejammer.org/ svk - http://svk.elixus.org/ Vesta- http://www.vestasys.org/ Xdelta - http://sourceforge.net/projects/xdelta I may have missed a few a quick google finds a list with descriptions of some others of which I am not familiar: http://dmoz.org/Computers/Software/Configuration_Management/Tools/ It is true that cvs works well at managing sources, but it is not always the best tool for the job if you have a complex environment. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFA0jck3x41pRYZE/gRApo9AKCJ5yPZ/qNl9cujOeOMRaDU/XQhIgCfY5yX GvKypvdButdp2GYFBiyJE3w= =UKvN -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
On Thu, 2004-06-17 at 18:16, Greg A. Woods wrote: > > Hm. Why not simply check these jar files into the repository where they > > can be tagged/branched/exported and so forth? Why should every > > programmer on my team need to get all the versions of each jar file laid > > out on his machine when he could just do a "cvs up" to get the current > > stuff for his branch? > > Don't you have a build system? (apparently you do going by your later > comments) Yup, Ant. > If you have many and diverse build machines then put your static > (i.e. non-changing) components on a central machine in a public > directory and have your build system invoke the appropriate tool to copy > them into the build environment as necessary. If you do that, and if > the way you reference those components includes information about their > version numbers (e.g. in the name of the directory they're "installed" > in), and if your build system is configured using normal source files > (e.g. text makefiles) that you commit to your CVS repository, then CVS > will track which version of which component is needed for every release. I think this might be a difference in the way Java apps do dependencies. I certainly agree that if I write, say, a C++ app that manages a PostgreSQL database, I won't ship PostgreSQL along with my app. I'll assume the user has it on there already, and the other guys who are developing with me will install PostgreSQL on their machines as well. But if I have two Java applications, each of which uses, say, JFreeChart, I expect each of them to come with a lib/ directory that has the version of JFreeChart they expect to use. There just isn't a Java standard - that I'm aware of - that expects Java jar files to go in /usr/lib or whereever. It's just not the done thing. So keeping 3rd party dependencies (i.e., a single jar file) in the repo is std practice. You've got a good point though - why aren't Java apps installed in a well-known location in the filesystem like everything else? Dunno. Yours, Tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
--- Lars <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > --- "Mark D. Baushke" <[EMAIL PROTECTED]> wrote: > > > >>Checking in binary files is not encouraged for cvs > >>use. > > > > Well what can I do ? It happends that my project > (a > > web site) includes binary files... > > > > > Here is a list which you can use as a starting point > after checking > which file types are applicable for your system of > course: > > http://www.durak.org/cvswebsites/howto-cvs/node38.html > Thanks, I modified my cvswrappers file a while ago. However I still check in binary files, which I hear (and believe) cvs can handle well, but it's not encouraged __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
[ On Thursday, June 17, 2004 at 17:34:20 (-0400), Jim.Hyslop wrote: ] > Subject: RE: CVS corrupts binary files ... > > Ah, I think I've spotted the root of this disagreement. I was not talking > about static information, but binary information that can, and does, change. Yeah, well pay attention to the actual requirements of the O.P. (which were for primarily _static_ data), not something you've dreampted up on your own. -- 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: CVS corrupts binary files ...
[ On Thursday, June 17, 2004 at 15:49:39 (-0700), Paul Sander wrote: ] > Subject: RE: CVS corrupts binary files ... > > Nope, I got it. The thing is, you can control pointers (e.g. makefiles > containing references to files stored in a library somewhere) all you > want, but that buys you nothing unless the targets of the pointers are > also tightly controlled. No, you didn't "get it". You seem to be among the many people who always forget to keep in mind what CVS is _not_. For example: CVS is not a complete software configuration management system. Most folks don't expect their C compiler to track changes to files any more than they expect their Make program to compile C code or interpret Python code. Anyone using CVS as a change tracking tool _must_ have some encompassing software configuration management system as well. If that encompassing SCM system does not have "tight control" over _all_ of the components and procedures and processes used in the production of the software products then it is certainly not the fault of CVS. Also what you and many other folks seem to forget as well is that manual procedures and processes can be far easier and more effective than canned software tools for implementing some parts of a complete SCM system. Furthermore those who expect one tool to do everything for them are living in a world of pure fantasy. Software development is first and foremost a process driven by people, not just other software. -- 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: CVS corrupts binary files ...
Greg A. Woods wrote: While I agree with most of what you wrote, I'd like to examine this one a little more: > Also what you and many other folks seem to forget as well is > that manual procedures and processes can be far easier and > more effective than canned software tools for implementing > some parts of a complete SCM system. Any manual procedure is prone to error. I prefer to automate things as much as possible, to minimize the possibility of human error. Any time I see a manual process, I wonder how it could be automated. I'm *not* saying that one tool, or even a variety of canned tools, will do the job - the automation could be as simple as a batch file or script that issues the appropriate commands in the correct sequence (with appropriate error checking). -- 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 corrupts binary files ...
[ On Monday, June 28, 2004 at 11:00:23 (-0400), Jim.Hyslop wrote: ] > Subject: RE: CVS corrupts binary files ... > > Any manual procedure is prone to error. I prefer to automate things as much > as possible, to minimize the possibility of human error. Any time I see a > manual process, I wonder how it could be automated. While I will agree in part, I'll also point out that even NASA sill uses paper checklists. :-) Perhaps it would be instructive for those grappling with the complexities of build systems, and version control integration, and other components of a complete software configuration management system to examine the likes of NetBSD's build system. For the last year or so NetBSD can be built from source to CD-ROM on a variety of non-NetBSD systems (as well as on NetBSD itself too of course) with a single command that first constructs all the necessary tools within the host environment and then uses them to compile the NetBSD sources. The host environment only needs a decent POSIX-compatible C compilation and execution environment and a few special tools such as mkisofs. If I'm not mistaken you can even build NetBSD on a Microsoft-NT host (after installing Cygwin), and except for a couple of problems with GCC cross-compilation, you can target any of the 16 (and 1/2 :-) unique CPU architectures NetBSD runs on, for any of the 52 different kinds of machines which are supported. For example I always build my own NetBSD/sparc installation media on my much faster i386 development systems (which run NetBSD/i386). The result is, so far as I know, byte-for-byte and bit-for-bit identical no matter which host platform it was constructed on. The complete NetBSD build system "source" is integrated directly into the whole source tree (and it's all just shell scripts and makefiles, with all the build tools being host-compiled copies of the NetBSD development system itself). Now as for NetBSD and CVS, well NetBSD does use CVS exclusively not only as their official change tracking tool and as part of their release management system, but also as a _public_ source distribution mechanism. As a result there are indeed a very few more-or-less static binary files in the repository. However they have been uuencoded into ASCII text format, and they are never changed by NetBSD developers. I.e. external, manually implemented, rules govern how these files are managed. In a less public project these files would better be treated in the same way as other host tools (e.g. mkisofs) -- they would be separately managed and installed on the build system(s), just as I've described should be done with such files. Independent external management of these doesn't work well for NetBSD because of the need to make these files available in the build environment without having network access at the time of the build. (BTW, NetBSD-2.0, now in beta-testing, will also cross-compile all of the X11 system for the target platform too.) -- 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: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Thursday, June 17, 2004 at 15:49:39 (-0700), Paul Sander wrote: ] >> Subject: RE: CVS corrupts binary files ... >> >> Nope, I got it. The thing is, you can control pointers (e.g. makefiles >> containing references to files stored in a library somewhere) all you >> want, but that buys you nothing unless the targets of the pointers are >> also tightly controlled. >No, you didn't "get it". >You seem to be among the many people who always forget to keep in mind >what CVS is _not_. For example: CVS is not a complete software >configuration management system. You are correct: CVS is a version control system. And it does version control only. That means that it archives collections of files for later reproducibility as a set (by label or branch/timestamp) or individually. And it does so without regard to the content of the files, though it works best with files that contain only ASCII text. What CVS does NOT do includes but is not limited to the following: Compiling or building software from sources (i.e. build procedure); packaging, installing, configuring, or deploying software produced by a build procedure; passing collections of versions around and tracking their progress through the development process (i.e. change control). Furthermore, all of these must be repeatable procedures that produce identical results when given identical inputs (or if not bit-for-bit identical results then at least bug-for-bug compatible results), and as output they must also record all inputs and outputs so that specific results can be reproduced at will. That means that the procedures must remember environment variable settings, command line parameters, baseline references, profiling and debugging flags, the operating system version and patch level (and sometimes even the hardware configuration), and a bazillion other things in such a way that they're readily available so that someone can either a) run a procedure that's identical to another one but with one or more specific and controlled variations, or b) reproduce the results of a past build exactly. And if a procedure fails for some reason (e.g. dangling baseline pointer or OS incompatibility) then it must diagnose the reason so that humans can perform the necessary recovery. >Anyone using CVS as a change tracking tool _must_ have some encompassing >software configuration management system as well. If that encompassing >SCM system does not have "tight control" over _all_ of the components >and procedures and processes used in the production of the software >products then it is certainly not the fault of CVS. This much is true, also. Version control is not sufficient on its own to build a good SCM system. All of the pieces I listed above that CVS does NOT do are also necessary components. Some of these pieces are readily available, and others must be built. However, getting back to the issue that originated this thread, there remains the question of what to do with code drops from external sources (particularly drops that are delivered in binary form). I maintain that such code drops must be handled as any other sources: Put them under source control, and apply the necessary change, build, and deployment procedures to treat it like any other part of the product. Contrast this with Greg's recommendations, which I reproduce here: ++> From: Greg A. Woods ++> Subject:Re: CVS corrupts binary files ... ++> Date: Tue, 8 Jun 2004 17:15:29 -0400 (EDT) ++> [ On Saturday, June 5, 2004 at 13:01:48 (-0700), Adrian Constantin wrote: ] ++> > Subject: Re: CVS corrupts binary files ... ++> > ++> > I don't wanna merge binary files, and I'm not likely ++> > to modify them in my module (project). I just want cvs ++> > to carry them along with the sources ++> Then your better tool is called a "directory" (i.e. outside of CVS) and ++> you use it with a simple reference to it from within your build system. ++> -- ++> Greg A. Woods and here: ++> From: Greg A. Woods ++> Subject: Re: CVS corrupts binary files ... ++> Date: Thu, 17 Jun 2004 16:12:15 -0400 (EDT) ++> [ On Wednesday, June 9, 2004 at 09:35:37 (-0400), Tom Copeland wrote: ] ++> > Subject: Re: CVS corrupts binary files ... ... ++> > Most of my Java projects use 3rd party jar files, ++> > which are compressed tar balls, more or less. And I certainly don't ++> > want to try to merge foolib-0.1.jar with foolib-0.2.jar when a new ++> > version comes out; I just want to put it in CVS so that it gets tagged ++> > and exported and so forth. ++> No, you REALLY DO NOT want (or need) to do that. What a waste. ++> What you should do is treat t
RE: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Monday, June 28, 2004 at 11:00:23 (-0400), Jim.Hyslop wrote: ] >> Subject: RE: CVS corrupts binary files ... >> >> Any manual procedure is prone to error. I prefer to automate things as much >> as possible, to minimize the possibility of human error. Any time I see a >> manual process, I wonder how it could be automated. >While I will agree in part, I'll also point out that even NASA sill uses >paper checklists. :-) I know people who work for NASA, and I know people who have worked for NASA in the past. They have a saying at NASA: "It was good enough to get us to the moon, so it's good enough for this." Twenty years ago, they really meant it. When you speak about how great NASA is and mention the antiquity of some of their processes, remember that the paper checklists have since contributed to the failure of several missions (some of which missed entire planets) and the loss of 14 lives. Also remember that a modern wristwatch carries more computing power than the spacecraft that orbited and landed on the moon, and a modern cell phone has more computing power than the whole of NASA had in those days. In a time when mission critical software was only hundreds or a few thousands of bytes in size, it could be managed with paper checklists. Today that is no longer the case, at least not unless you're willing to tolerate a much higher level of risk. So NASA is learning that what worked well in the past may not necessarily work well in the future, maybe not even today. Reliability is the order of the day, and it turns out that reliability of a given procedure varies inversely with the number of fingers poking it. And today that saying is spoken in jest. >Perhaps it would be instructive for those grappling with the >complexities of build systems, and version control integration, and >other components of a complete software configuration management system >to examine the likes of NetBSD's build system. NetBSD is awesome! But keep in mind that the reason they can do what they do is that they literally own the entire environment, from the OS and system libraries on up. Yes, they have to build cross environments, but after they've built the cross compiler twice the runtime environment of the build system really doesn't matter as long it can schedule CPU time and access files. Most of us don't have that luxury. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
[ On Monday, June 28, 2004 at 18:31:58 (-0700), Paul Sander wrote: ] > Subject: RE: CVS corrupts binary files ... > > On three separate occasions, Greg actually *recommends* intalling and > treating such code drops as uncontrolled sources! Paul, please stop mirepresenting what I have said. (A) they're not "sources" -- they're intermediate product files. (B) installing third-party intermediate files on the build systems doesn't mean they are "uncontrolled" -- only in _your_ mind could that be true. > Dropping stuff in > a directory and pointing makefiles at it is just plain bad CM. Indeed it would be, if that was all one did. Let me repeat again since you obviously don't grasp the full and deep meaning of this statement: CVS is _NOT_ a _complete_ software configuration management system. Obviosly anyone interested in good SCM will have external procedures to account for these third-party files, just as they should have procedures for dealing with _all_ attributes of their build environment. > (Well, that last statement has limits in practicality; there's a break- > even point where the the benefit of automation exceeds the cost of > automation, but that point is usually relatively low, especially in the > CM domain.) Exactly. You've been riding your high horse for so long now that you're clearly having troubles dealing with real-world issues. -- 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: CVS corrupts binary files ...
[ On Tuesday, June 29, 2004 at 19:34:25 (-0700), Paul Sander wrote: ] > Subject: RE: CVS corrupts binary files ... > > When you speak about how great NASA is and mention the antiquity of some > of their processes, remember that the paper checklists have since > contributed to the failure of several missions (some of which missed > entire planets) and the loss of 14 lives. Have you not read the investigation reports on all those incidents? The concept of using "paper checklists" as part of their process did not contributed in any way to those failures. Indeed their ability to investigate those incidents is in no small part aided by the existance of those paper checklists. > NetBSD is awesome! Of course -- that's why I've come to use it almost exclusively. ;-) > But keep in mind that the reason they can do what they do is that they > literally own the entire environment, from the OS and system libraries > on up. Well, Duh! That's the whole point here! If you want to control your software development process from top to bottom then you must "own" the whole environment -- from the build environment and tools and such through to all directly included components of the system. > Yes, they have to build cross environments, but after they've > built the cross compiler twice the runtime environment of the build > system really doesn't matter as long it can schedule CPU time and access > files. Most of us don't have that luxury. You create the situations you yourself must live with. NetBSD is only interesting in this respect because the whole project, and indeed multiple working branches of it, can be checked out entirely from one big CVS repository. (keeping in mind that the manual rules for developers dealing with that repository are not exactly trivial, especially in the special-case situations I mentioned) In fact in in all successful development environments for critical software, and most for embedded software, that I've ever encountered there's a similar level of "ownership" over all tools and components -- however it's extremely rare to find anyone using CVS as exclusively as NetBSD is able to do (unless they are also using NetBSD :-), partly because few groups are willing to live under the restrictions this causes (it's far easier to use a manual checklist to ensure the right versions of all the right tools and third-party components is installed on a build system). (So far it's been the unsuccessful, or struggling, development groups I've encountered who have been the ones who have failied to take "ownership" over all their software components.) -- 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: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Monday, June 28, 2004 at 18:31:58 (-0700), Paul Sander wrote: ] >> Subject: RE: CVS corrupts binary files ... >> >> On three separate occasions, Greg actually *recommends* intalling and >> treating such code drops as uncontrolled sources! >Paul, please stop mirepresenting what I have said. >(A) they're not "sources" -- they're intermediate product files. They're not "intermediate product files" unless they can be reproduced from some other source using an established process. The code drops we're discussing come from outside and are the definitive *sources* of the data that they contain, and can't change (or be recovered if lost) without human intervention. By definition, they are source files. >(B) installing third-party intermediate files on the build systems >doesn't mean they are "uncontrolled" -- only in _your_ mind could >that be true. They are, if there's no control over them. Simply installing them is not controlling them. If you can't control them, then you must remember all aspects that you can measure. If you don't then something will break as a result an uncontrolled change being introduced, and the problem will be potentially very hard to detect, correct, and prevent in the future. >> Dropping stuff in >> a directory and pointing makefiles at it is just plain bad CM. >Indeed it would be, if that was all one did. In all of the articles posted so far on this thread, you have suggested nothing more. What do you have in mind, in addition to what you've said? >Let me repeat again since you obviously don't grasp the full and deep >meaning of this statement: CVS is _NOT_ a _complete_ software >configuration management system. READ MY KEYS: I agree that CVS is not a complete software configuration system. In the very message that you snipped above, I listed a number of things that must be done with files like this, starting with a tuning/build/installation/deployment method that itself undergoes good CM. CVS is used only for the version control part, archiving the incoming sources and providing a convenient extraction method that happens to be the same one that tracks all other sources in the product. >Obviosly anyone interested in good SCM will have external procedures to >account for these third-party files, just as they should have procedures >for dealing with _all_ attributes of their build environment. Cool. We agree on something. It's good when you say what you mean. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
[ On Wednesday, June 30, 2004 at 22:59:27 (-0700), Paul Sander wrote: ] > Subject: RE: CVS corrupts binary files ... > > >(A) they're not "sources" -- they're intermediate product files. > > They're not "intermediate product files" unless they can be reproduced > from some other source using an established process. Yes, they are intermediate product files. Just because their ultimate source code is managed by someone else doesn't change the fact that they are not sources for the local project -- indeed it only confirms it. The "established process" is to repeat whatever process you did to get a copy of those intermediate product files in the first place! What's so bloody hard to understand about this? It's extremely basic!!! -- 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: CVS corrupts binary files ...
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Wednesday, June 30, 2004 at 22:59:27 (-0700), Paul Sander wrote: ] >> Subject: RE: CVS corrupts binary files ... >> >> >(A) they're not "sources" -- they're intermediate product files. >> >> They're not "intermediate product files" unless they can be reproduced >> from some other source using an established process. >Yes, they are intermediate product files. Just because their ultimate >source code is managed by someone else doesn't change the fact that they >are not sources for the local project -- indeed it only confirms it. In other words, you're trying to integrate your vendor's CM process into some global, all-encompassing process that also happens to include yours? Well, in my world, there are boxes around my process and my vendors. The boxes have well-defined inputs and outputs, and anything in my box is subject to my process. And artifacts that can't be derived from other artifacts automatically are treated like sources. And rightly so. >The "established process" is to repeat whatever process you did to get a >copy of those intermediate product files in the first place! >What's so bloody hard to understand about this? It's extremely basic!!! So, what you're proposing is to use the vendor's distribution media and an offline archival system for version control, and a written installation procedure to put it somewhere (hoping that whatever local configuration options get used once are repeated next time), and assuming that the installation procedure provides a hook so that you can manage your installations as baselines? And you re-install by hand and patch for every bug fix? Yeah. Right. Get real. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
[ On Friday, July 2, 2004 at 12:49:58 (-0700), Paul Sander wrote: ] > Subject: RE: CVS corrupts binary files ... > > >--- Forwarded mail from [EMAIL PROTECTED] > > >[ On Wednesday, June 30, 2004 at 22:59:27 (-0700), Paul Sander wrote: ] > >> Subject: RE: CVS corrupts binary files ... > >> > >> >(A) they're not "sources" -- they're intermediate product files. > >> > >> They're not "intermediate product files" unless they can be reproduced > >> from some other source using an established process. > > >Yes, they are intermediate product files. Just because their ultimate > >source code is managed by someone else doesn't change the fact that they > >are not sources for the local project -- indeed it only confirms it. > > In other words, you're trying to integrate your vendor's CM process into > some global, all-encompassing process that also happens to include yours? Oh, come on now Paul! How much detail do I have to give you? I thought you had enough experience with SCM by now that you'd understand how to manage third party components with the appropriate tools! You're sounding more like a politician every time! Jumping off in yet another wrong direction, perhaps just for the sake of debate, every time I try to put you on the right track again. NO, I am not even suggesting that the vendor's CM process be accounted for in any way. I'm saying quite simply that intermediate product files are what they are regardless of who produces them. If you don't know how to track the components of your software using your own processes, i.e. over and above and outside of CVS, then I've got to wonder if you have any SCM outside of CVS. Remember CVS is not a complete configuration management system. I know you know that but I seem to have to keep pointing it out to you almost continuously. > Well, in my world, there are boxes around my process and my vendors. You've got to learn to think outside your box! (and especially to think outside of the box CVS works within) -- 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: CVS corrupts binary files ...
>--- Forwarded mail from Greg Woods: >[ On Friday, July 2, 2004 at 12:49:58 (-0700), Paul Sander wrote: ] >> Subject: RE: CVS corrupts binary files ... >> >> >--- Forwarded mail from [EMAIL PROTECTED] >> >> >[ On Wednesday, June 30, 2004 at 22:59:27 (-0700), Paul Sander wrote: ] >> >> Subject: RE: CVS corrupts binary files ... >> >> >> >> >(A) they're not "sources" -- they're intermediate product files. >> >> >> >> They're not "intermediate product files" unless they can be reproduced >> >> from some other source using an established process. >> >> >Yes, they are intermediate product files. Just because their ultimate >> >source code is managed by someone else doesn't change the fact that they >> >are not sources for the local project -- indeed it only confirms it. >> >> In other words, you're trying to integrate your vendor's CM process into >> some global, all-encompassing process that also happens to include yours? >Oh, come on now Paul! How much detail do I have to give you? I thought >you had enough experience with SCM by now that you'd understand how to >manage third party components with the appropriate tools! I know how absurd it sounded, but I had to ask to make sure I understood what you were saying. And you really aren't making a lot of sense. >NO, I am not even suggesting that the vendor's CM process be accounted >for in any way. Whew! That's good! >I'm saying quite simply that intermediate product files are what they >are regardless of who produces them. Intermediate product files are things like .o files, which are neither sources nor shippables, but are an essential part of the overall build process. Because they can be rebuilt at will from existing sources using a repeatable procedure, their retention is not required and sometimes is not even desirable. This appears to be the basis of our disagreement: For me, "intermediate product files," as I've defined them above, can be deleted and rebuilt at will. Products that come from outside sources do not fit this description. Because products from outside sources, for all intents and purposes, cannot be re-created without human intervention, they require an archival method that can re-create any coherent sets files supplied by the vendor at any time. That's precisely what version control is good for, and that's why I check in everything I receive from any vendor. By using CVS as my only version control tool, I don't need variants of all of my other tools that interface to version control. Additionally, my build processes manage storage and baseline references automatically, and they provide a consistent interface at the top level to facilitate automated scheduling. That means that whatever build and installation procedures that exist must have a consistent interface. In my case, I have a limited set of hooks to allow for per-build refinements (e.g. a Gnu compatible makefile in the top of the source tree that implements an "all" target) and also publishes its outputs (e.g. search paths for use by other builds, packing lists and shippables, etc.). In this environment, it is *possible* to hand-craft baseline builds for third-party products (as you suggest), but it is **far easier** (in the long run) to treat them like source code because all of the power of the existing environment is brought to bear to manage them. >If you don't know how to track the components of your software using >your own processes, i.e. over and above and outside of CVS, then I've >got to wonder if you have any SCM outside of CVS. Remember CVS is not a >complete configuration management system. I know you know that but I >seem to have to keep pointing it out to you almost continuously. My processes track all of the inputs to my processes. They also track artifacts that are automatically managed (e.g. baseline references), as well as artifacts that can't be controlled (e.g. the operating system and patch level on the build machine). It turns out that, although such traceability records are outputs of my build procedures, they represent sources that cannot be automatically reproduced exactly, so they are also checked in and become input to the tools that reproduce old builds. >> Well, in my world, there are boxes around my process and my vendors. >You've got to learn to think outside your box! >(and especially to think outside of the box CVS works within) The power convenience given to me by the contents of the box makes compelling reason to stay inside it. Although the interfaces are fixed, they are pretty generic. Thin abstraction layers provide sufficient flexibility to accomodate the requi
Smoke, FUD (was Re: CVS corrupts binary files ...)
Whew, the smoke's getting thick in here! >From: [EMAIL PROTECTED] >[ On Thursday, June 17, 2004 at 13:06:44 (-0700), Paul Sander wrote: ] >> Subject: Re: CVS corrupts binary files ... >> >> Current releases of CVS do the latter. (Don't believe me? Look at >> the function named RCS_merge in the rcscmds.c source file.) It's a >> simple matter to replace the invocation of diff3 with a different tool. >Huh!?!?!? >Since when does the phrase "diff and diff3 algorithms" identify any >particular program that might implement those algorithms? Then you don't object to swapping the diff and diff3 programs out for others that might apply other 2-way and 3-way differencing algorithms that are more appropriate to the data at hand, for purposes other than maintainting the integrity of the RCS file format? If this is true, then we're in violent agreement. But to date, you have argued that making the necessary changes to CVS to give better support for data types not handled well specifically by the diff and diff3 programs would break compatibility with RCS, which is demonstrably false. The maintenance of version history is sufficiently insulated from the user interfaces of the content merge features that there is simply no credible argument on that basis. >Paul, _you_ are the one spreading FUD here. How am I spreading Fear, Uncertainty, or Doubt? I'm claiming that CVS is capable of doing more than it does, with only minor changes (i.e. none that have significant impact on its architecture). There's no FUD here, other than what's in your head. The world won't end if CVS changes its merge tool, Greg. Get over it. >In case you have forgotten I am intimately familiar with exactly how the >GNU diffutils code and the GNU patch code is integrated into the CVS >source. Not so intimate that you fully understand how the CVS design constrains the effects of certain kinds of changes, apparently. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
[ On Thursday, June 17, 2004 at 16:49:42 (-0700), Paul Sander wrote: ] > Subject: Smoke, FUD (was Re: CVS corrupts binary files ...) > > If this is true, then we're in violent agreement. But to date, you have > argued that making the necessary changes to CVS to give better support > for data types not handled well specifically by the diff and diff3 programs > would break compatibility with RCS, which is demonstrably false. Have you not looked at the content of an RCS file lately Paul? RCS compatability is far more than just the adherence to the syntax defined in rcsfile(5). If the generic "co" program from the RCS package cannot extract any and every revision of a file from a file claiming to be an RCS file then that file is clearly not RCS compatible. > How am I spreading Fear, Uncertainty, or Doubt? Maybe hypocrisy would be a better description of your approach to CVS. -- 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: Smoke, FUD (was Re: CVS corrupts binary files ...)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Greg, Greg A. Woods <[EMAIL PROTECTED]> writes: > RCS compatability is far more than just the > adherence to the syntax defined in rcsfile(5). Is it? I think I must be missing something here. The RCS format is very extensible and in fact the CVSNT folks have extended it already and I have had no problems using CVSNT repositories in conjunction with either CVS or RCS. > If the generic "co" program from the RCS package > cannot extract any and every revision of a file > from a file claiming to be an RCS file then that > file is clearly not RCS compatible. Sure, I agree with your statement. If a generic "co" program is not able to extract any and every revision of a file from its file,v form, then it is not RCS compatible. I do not see support for your assertion that compatibility is "far more" than just the adherence to the syntax defined in rcsfile(5). In particular, I am not aware of any fundamental problems rcs 5.7 will have if someone were to introduce a new keyword which would name a program other than diff3 to be used in rcsmerge operations. At most, I would expect a warning message via the warnignore() function which would specify co: file,v: warning: Unknown phrases like `diff3hint ...;' are present. and even so, a 'co -q file,v' would not generate such a message. So, I believe that adding a 'diff3hint someprogram;' line to the RCS file should not be a problem for "co" to still be able to checkout each and every version of the file. Given that this would appear to be the desire of at least a few folks out there who might want to make CVS do a better job at merging structured ASCII files such as XML or HTML format. And further, that you seem to have objections to this approach. And while I have known you to bring up points I have overlooked in the past... This time around I just do not see anything that would preclude such an approach of using an external diff3 hint 'replacement' program for doing a 'cvs update -jtag1 -jtag2' operation. I will stipulate that such a program will likely need to live on the server and furthermore that it would not be interactive. In the absense of finding such a program, CVS would likely resort to using diff3 as a fallback, so its arguments would likely need to match those of the diff3 program itself... at least to the extent that cvs currently uses various arguments to diff3. So, as I trust that you have an example in mind that is a conflicting case, I must clearly be missing something here. I would take it is a favor if you could ellaborate in concrete terms why adding a new keyword and value to existing RCS format files to support an alternative to diff3 is not a viable path for a hook that users may wish to exercise. If there is some other communication error that has entered into the thread, I must have missed it. Feel free to point it out, but I would still be interested in your view of the following thought experiment. Let me state the scope of the thought experiment: Goal: Provide a means whereby a cvs administrator may cause a program other than diff3 to be used when doing merge operations as a part of a three-way merge of files in a sandbox. This program might be defined as a keyword used as the value of a 'diff3hint' followed by an 'id' which could be looked up in a table that cvs could keep to determine which executable and any additional arguments above the diff3 form arguments might be required. Assertion: The diff3 replacement must handle all of the args that cvs normally passes to diff3. Assertion: The diff3 replacement must not be interactive in nature for client/server repository uses. Assertion: The diff3 replacement must be able to run just given the three versions of the file without any other state. Assertion: That cvs continue to write new RCS files in adherence to the syntax defined in rcsfile(5), but allowing the introduction of one or more new phrases and associated id word values as allowed for by the RCS format syntax. It would be left to the extension designer to determine the method whereby such a new RCS phrase would be written into the CVS repository versions of the files. Thanks, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFA39pz3x41pRYZE/gRAhjEAJ94c9uKJEwZww8lGAFGQJW68vvEswCfX3Ae HoyCY1oAu/1+v9jOMxBXflE= =u1L8 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
[ On Monday, June 28, 2004 at 01:44:36 (-0700), Mark D. Baushke wrote: ] > Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) > > The RCS format is very extensible and in fact the > CVSNT folks have extended it already and I have had > no problems using CVSNT repositories in conjunction > with either CVS or RCS. "very" is an over-statement of the first order! ;-) Sure, it's an extensible format, but not in the way that's been suggested. You can't get rid of the _exclusive_ use of diff et al without entirely losing compatabilty with RCS. > I do not see support for your assertion that > compatibility is "far more" than just the > adherence to the syntax defined in rcsfile(5). Sadly rcsfile(5) only describes the meta-syntax, not the nuts&bolts of how RCS files work and how they're actually used by the RCS package. > So, I believe that adding a > > 'diff3hint someprogram;' > > line to the RCS file should not be a problem for > "co" to still be able to checkout each and every > version of the file. "diff3hint" in the way you're hinting it might be used is insufficient. RCS directly interprets the content of the delta text information, e.g. the likes of: @d5 1 a5 1 some new line of text d256 1 @ See, for example, lib/rcsedit.c from the RCS source distribution. Any modification of the diff algorithm would almost certainly require changes to the syntax of this delta text. As far as I can tell the extensibility of the RCS,v syntax does not go so far as to provide for callouts to add-on programs and I'm arguing that it's _far_ too late to try to modify this widely used standard file format now. So, how _exactly_ do you propose to convince the standard "co" program (or the equivalent in any other RCS-compatible tool suite, including the current CVS implementations) to actually make use of the new delta text syntax that such a hack would create? I.e. How do you propose to make it possible for the standard RCS tools alone to re-create _every_ revision from all files created by this hacked system? It's simply not possible. Like I said, only the bare surface of RCS compatability is scratched by the meta-syntax described in rcsfile(5). The RCS file format is intricately intertwined with the unix diff algorithm, which is itself tightly dependent on the "normal" use of lines of text to represent elements of a the source files being managed (at least when it comes to automated merging for concurrent editing). Meanwhile there are other change delta file formats and other version tracking tools that use those other formats, and often there are also tools that will convert RCS/CVS repositories into those other formats. I.e. there's no _real_ fundamental need to hack on RCS,v syntax. -- 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: Smoke, FUD (was Re: CVS corrupts binary files ...)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg A. Woods <[EMAIL PROTECTED]> writes: > [ On Monday, June 28, 2004 at 01:44:36 (-0700), Mark D. Baushke wrote: ] > > Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) > > > > The RCS format is very extensible and in fact the > > CVSNT folks have extended it already and I have had > > no problems using CVSNT repositories in conjunction > > with either CVS or RCS. > > "very" is an over-statement of the first order! ;-) Agreed. :-) > Sure, it's an extensible format, but not in the > way that's been suggested. You can't get rid of > the _exclusive_ use of diff et al without > entirely losing compatabilty with RCS. Yes, but diff is not diff3. diff is used for the delta format. diff3 is used by rcsmerge, not for fundamental version deltas. > > I do not see support for your assertion that > > compatibility is "far more" than just the > > adherence to the syntax defined in rcsfile(5). > > Sadly rcsfile(5) only describes the meta-syntax, > not the nuts&bolts of how RCS files work and how > they're actually used by the RCS package. True, but examiniation of the rcs sources (or cvs sources) can help you a lot. > > So, I believe that adding a > > > > 'diff3hint someprogram;' > > > > line to the RCS file should not be a problem > > for "co" to still be able to checkout each and > > every version of the file. > > "diff3hint" in the way you're hinting it might > be used is insufficient. Why? > RCS directly interprets the content of the delta > text information, e.g. the likes of: > > @d5 1 > a5 1 > some new line of text > d256 1 > @ > > See, for example, lib/rcsedit.c from the RCS > source distribution. Yes, and that is the concern of 'diff' NOT 'diff3'. My assumptions explicitly did NOT address any requirements other than that a 'diff3' replacement be used. Where did your assertion that this requires 'diff' to be changed arise? > Any modification of the diff algorithm would > almost certainly require changes to the syntax > of this delta text. I did not suggest modification of the diff format. I suggested modification of the diff3 program to be used. > As far as I can tell the extensibility of the > RCS,v syntax does not go so far as to provide > for callouts to add-on programs and I'm arguing > that it's _far_ too late to try to modify this > widely used standard file format now. With existing RCS, you may compile it to use DIFF3_BIN as any path you wish. There is nothing to guarentee that the diff3 does what the GNU diff3 program did... > So, how _exactly_ do you propose to convince the > standard "co" program (or the equivalent in any > other RCS-compatible tool suite, including the > current CVS implementations) to actually make > use of the new delta text syntax that such a > hack would create? I propose that "co" use "diff" just as it has always done. I am not proposing any change to the delta structure at all. The thought experiment is proposing a change in the function called to do three way diff and merge operations. > I.e. How do you propose to make it possible for > the standard RCS tools alone to re-create > _every_ revision from all files created by this > hacked system? What I suggested does not require this. > It's simply not possible. You say this, but are assuming facts that were not supported. Why does a change to 'diff3' for merge operations imply or require a change to 'diff' for everything else? > Like I said, only the bare surface of RCS > compatability is scratched by the meta-syntax > described in rcsfile(5). Why or how would a change in diff3 impact delta formats for RCS? The DIFF3 binary is used only in rcs-5.7/src/merger.c and plays no direct role in checkout or commit of RCS files. > The RCS file format is intricately intertwined > with the unix diff algorithm, Actually, I suspect this to be false. I believe the RCS delta section format is intertwined with the ed(1) command format. > which is itself tightly dependent on the > "normal" use of lines of text to represent > elements of a the source files being managed (at > least when it comes to automated merging for > concurrent editing). And all of that is not material to the current thought experiment. > Meanwhile there are other change delta file > formats and other version tracking tools that > use those other formats, and often there are > also tools that will convert RCS/CVS > repositories into those other formats. I.e. > there&
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
>--- Forwarded mail from Greg Woods: >[ On Thursday, June 17, 2004 at 16:49:42 (-0700), Paul Sander wrote: ] >> Subject: Smoke, FUD (was Re: CVS corrupts binary files ...) >> >> If this is true, then we're in violent agreement. But to date, you have >> argued that making the necessary changes to CVS to give better support >> for data types not handled well specifically by the diff and diff3 programs >> would break compatibility with RCS, which is demonstrably false. >Have you not looked at the content of an RCS file lately Paul? >RCS compatability is far more than just the adherence to the syntax >defined in rcsfile(5). If the generic "co" program from the RCS package >cannot extract any and every revision of a file from a file claiming to >be an RCS file then that file is clearly not RCS compatible. I have never, ever advocated changing the format of an RCS file in a way that would break the ci, co, rcs, or rlog programs. And although I strongly advocate the replacement of user-exposed diff and merge tools, I have never, ever advocated the replacement of the diff tool that computes the deltas stored in an RCS file. (That is not to say that I have never suggested making incompatible changes, but in context such suggestions have always carried caveats and recognized the lack of desirability of losing a valuable feature.) I don't know where you seem to be getting the idea that I'm recommending doing a global search and replace of "diff" with some other tool. That is clearly not the case. The RCS file format must be retained, unless we as a group decide to abandon it after weighing the consequences. However, I do advocate extending the RCS file format in ways that the RCS API can accomodate. The rcsfile(5) manual specifically allows for extensions in the admin and delta sections of the file. For example, I do recommend using a newphrase in the admin section to identify the type of data stored in the file, but not until the rename problem is solved. >> How am I spreading Fear, Uncertainty, or Doubt? >Maybe hypocrisy would be a better description of your approach to CVS. I don't believe I'm misrepresenting any of my beliefs about CVS or SCM in general. I've tried very hard to explain them clearly, and I've tried especially hard to drill them into that rock that you carry on your shoulders, but I'm obviously using the wrong screwdriver. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
>--- Forwarded mail from [EMAIL PROTECTED] Mark, I agree with your response to Greg's claims about RCS compatibility, or the lack thereof. >In particular, I am not aware of any fundamental >problems rcs 5.7 will have if someone were to >introduce a new keyword which would name a program >other than diff3 to be used in rcsmerge >operations. At most, I would expect a warning >message via the warnignore() function which would >specify >co: file,v: warning: Unknown phrases like `diff3hint ...;' are present. >and even so, a 'co -q file,v' would not generate >such a message. >So, I believe that adding a >'diff3hint someprogram;' >line to the RCS file should not be a problem for >"co" to still be able to checkout each and every >version of the file. Rather than use a hint to expose an implementation detail, I suggest recording a data type instead. Maybe even a MIME type. Then provide a suitable mechanism to map data types to tools that are appropriate to the environment. BTW, CVS no longer uses rcsmerge; it co's the necessary versions and runs diff3 directly. So in a CVS context, pushing this capability down to RCS isn't really a requirement. However, I recognize the usefulness of doing so, and would not oppose such a feature. On the other hand, doing so will likely be a duplication of effort because CVS has client/server concerns that RCS does not, and that may necessitate a different implementation. >Given that this would appear to be the desire of >at least a few folks out there who might want to >make CVS do a better job at merging structured >ASCII files such as XML or HTML format. And >further, that you seem to have objections to this >approach. And while I have known you to bring up >points I have overlooked in the past... Not just structured ASCII files as you describe, but any file containing structured data for which a merge tool is available. >This time around I just do not see anything that >would preclude such an approach of using an >external diff3 hint 'replacement' program for >doing a 'cvs update -jtag1 -jtag2' operation. >I will stipulate that such a program will likely >need to live on the server and furthermore that it >would not be interactive. In the absense of >finding such a program, CVS would likely resort to >using diff3 as a fallback, so its arguments would >likely need to match those of the diff3 program >itself... at least to the extent that cvs currently >uses various arguments to diff3. I don't believe that such a program MUST live on the server. Merge tools, like editors, have a way of becoming religious icons, in situations where users have a choice. Under such circumstances, it becomes important to have client side mappings between data types and merge tools. Additionally, I don't believe that merge tools necessarily need to be fully automated. After the relevant versions have been downloaded to the client (and the repository locks have been cleared), the merge tools can run interactively. However, I believe that CVS current intersperses merges with downloads, and that would need to change before interactive merges can be supported. Also, CVS currently relies on diff3-style mark-ups to warn the user when merge conflicts remain present at commit time. Though strictly speaking such warnings are not necessary, they are incredibly useful. And they'll be lost unless merge conflicts are recorded another way. One way is to lists conflicts in a file stored in the CVS directory. At commit time, skip the scan for diff3 mark-ups and instead read the conflict list and compare mod times of the relevant files. If they have changed, assume the conflicts have been resolved. >Let me state the scope of the thought experiment: >Goal: Provide a means whereby a cvs administrator >may cause a program other than diff3 to be used >when doing merge operations as a part of a >three-way merge of files in a sandbox. This >program might be defined as a keyword used as the >value of a 'diff3hint' followed by an 'id' which >could be looked up in a table that cvs could keep >to determine which executable and any additional >arguments above the diff3 form arguments might be >required. Again, I think that recording a data type is a more straightforward (or at least more easily understood) implementation. >Assertion: The diff3 replacement must handle >all of the args that cvs normally passes to diff3. Yes. >Assertion: The diff3 replacement must not be >interactive in nature for client/server repository >uses. Well, okay for the first implementation. :-) >Assertion: The diff3 replacement must be able to >run just given the three versions of the file >without any other state. Yes, but it would be nice to be able to pass in the version numbers for column headings or the like, if the tool permits. >Assertion: That cvs continue to write new RCS files >in adherence to the syntax defined in rcsfile(5), but >allowing the introduction of one or more new phrases >and associated
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Monday, June 28, 2004 at 01:44:36 (-0700), Mark D. Baushke wrote: ] >> Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) >> >> The RCS format is very extensible and in fact the >> CVSNT folks have extended it already and I have had >> no problems using CVSNT repositories in conjunction >> with either CVS or RCS. >"very" is an over-statement of the first order! ;-) >Sure, it's an extensible format, but not in the way that's been >suggested. You can't get rid of the _exclusive_ use of diff et al >without entirely losing compatabilty with RCS. Nobody has suggested abandoning diff for computing RCS deltas. All discussion relating to replacement of diff and merge tools have revolved around the user interface. That's completely different. >> I do not see support for your assertion that >> compatibility is "far more" than just the >> adherence to the syntax defined in rcsfile(5). >Sadly rcsfile(5) only describes the meta-syntax, not the nuts&bolts of >how RCS files work and how they're actually used by the RCS package. >> So, I believe that adding a >> >> 'diff3hint someprogram;' >> >> line to the RCS file should not be a problem for >> "co" to still be able to checkout each and every >> version of the file. >"diff3hint" in the way you're hinting it might be used is insufficient. >RCS directly interprets the content of the delta text information, >e.g. the likes of: > @d5 1 > a5 1 > some new line of text > d256 1 > @ >See, for example, lib/rcsedit.c from the RCS source distribution. You are obviously missing something here. We're talking about adding a newphrase in the admin, delta, or deltatext productions. Using the deltatext production and your diff output as an example: 1.1 log @this is a log message @ diff3hint use-this-tool; text @d5 1 a5 1 some new line of text d256 1 @ This obviously extends the RCS file format in a way that does not break compatibility with the existing RCS software. Following is a complete RCS file that contains not one but three extensions, but they're done in a way that is supported by the RCS file format. And none of the RCS programmatic interfaces break. head1.4; access; symbols; locks; strict; comment @# @; admin-ext @this is an admin extension.@; 1.4 date2004.06.29.09.08.54;author paul;state Exp; branches; next1.3; 1.3 date2004.06.29.09.05.20;author paul;state Exp; branches; next1.2; delta-ext @this is a delta extension.@; 1.2 date2004.06.29.09.04.53;author paul;state Exp; branches; next1.1; 1.1 date2004.06.29.09.04.24;author paul;state Exp; branches; next; desc @Test file. @ 1.4 log @Added the beep! @ text @This is a test. This is only a test. If this had been an actual emergency, it would have been too late. BEP! @ 1.3 log @Done! @ deltatext-ext @this is a deltatext extension.@; text @d4 1 @ 1.2 log @First change. Needs more work. @ text @d3 1 @ 1.1 log @Initial revision @ text @d2 1 @ >Any modification of the diff algorithm would almost certainly require >changes to the syntax of this delta text. Actually, this isn't true. The diff program itself implements multiple algorithms. But that's neither here nor there because nobody is recommending that the format of the differences be changed. >As far as I can tell the extensibility of the RCS,v syntax does not go >so far as to provide for callouts to add-on programs and I'm arguing >that it's _far_ too late to try to modify this widely used standard file >format now. It's never too late to update a standard. In any case, RCS file extensibility has been in the standard for a very long time now. >So, how _exactly_ do you propose to convince the standard "co" program >(or the equivalent in any other RCS-compatible tool suite, including the >current CVS implementations) to actually make use of the new delta >text syntax that such a hack would create? >I.e. How do you propose to make it possible for the standard RCS tools >alone to re-create _every_ revision from all files created by this >hacked system? Simple: The delta text would not change. See above. >It's simply not possible. Like I said, only the bare surface of RCS >compatability is scratched by the meta-syntax described in rcsfile(5). Absolutely untrue, as demonstrated by the RCS file above. >The RCS file format is intricately intertwined with the unix diff >algorithm, which is itself tightly dependent on the "normal" use of >lines of text to represent elements of a the source files being managed This much is t
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander <[EMAIL PROTECTED]> writes: > >--- Forwarded mail from [EMAIL PROTECTED] > > Rather than use a hint to expose an > implementation detail, I suggest recording a > data type instead. Maybe even a MIME type. Then > provide a suitable mechanism to map data types > to tools that are appropriate to the > environment. I have no fundamental objection to saving the MIME type. I suggest that it may need to be inside of a string to pass the syntax of rcsfile(5). I would actually suggest that it might be useful to just borrow both of the MIME media-type and charset concepts. That might allow for a "media-type text/plain;" "charset ks_c_5601-1987;" on a given file... the defaults should probably be "text/plain" and iso-8859-1 or utf-8 > BTW, CVS no longer uses rcsmerge; it co's the > necessary versions and runs diff3 directly. So > in a CVS context, pushing this capability down > to RCS isn't really a requirement. However, I > recognize the usefulness of doing so, and would > not oppose such a feature. On the other hand, > doing so will likely be a duplication of effort > because CVS has client/server concerns that RCS > does not, and that may necessitate a different > implementation. Yes, I am aware that CVS no longer uses rcsmerge. However, Greg was suggesting that RCS compatibility would be broken by an extension such as the one outlined in the thought experiment I provided, so I felt it reasonable to mention how RCS itself used diff3 in the past. > >Given that this would appear to be the desire of > >at least a few folks out there who might want to > >make CVS do a better job at merging structured > >ASCII files such as XML or HTML format. And > >further, that you seem to have objections to this > >approach. And while I have known you to bring up > >points I have overlooked in the past... > > Not just structured ASCII files as you describe, > but any file containing structured data for > which a merge tool is available. Ahh, but I am not really trying to suggest that "binary files" are suitable in the general case for CVS control. That is a separate argument. That said, I suppose that a merge utility that understands how to merge a file containing lines in a non-ISO-LATIN character set might also fall into the category of a diff3 replacement and that such files might be considered 'binary' by some programs. > >This time around I just do not see anything that > >would preclude such an approach of using an > >external diff3 hint 'replacement' program for > >doing a 'cvs update -jtag1 -jtag2' operation. > > >I will stipulate that such a program will likely > >need to live on the server and furthermore that it > >would not be interactive. In the absense of > >finding such a program, CVS would likely resort to > >using diff3 as a fallback, so its arguments would > >likely need to match those of the diff3 program > >itself... at least to the extent that cvs currently > >uses various arguments to diff3. > > I don't believe that such a program MUST live on > the server. The changes needed to allow the client-side to do a merge are very large. I am not willing to stipulate an implementation that would allow CVS to deal with an interactive merge operation for a random 'cvs update' command. The repository would have a lock open for too long in that case. > Merge tools, like editors, have a way of > becoming religious icons, in situations where > users have a choice. Under such circumstances, > it becomes important to have client side > mappings between data types and merge tools. Your arguments almost help to make a case in Greg's favor against allowing a diff3 replacement. The kind of flexibility you desire is not something that I think makes sense to bolt into the 'diff3' slot. What you propose would potentially best be handled with an entirely new kind of update paradigm. Possibly the use of a CVS/Base/file file and a 'patch' that would bring CVS/Base/file up to the latest version would be 'better' in this case... > Additionally, I don't believe that merge tools > necessarily need to be fully automated. Here we do not agree. Without such automation, lock contention on directories could get very intense. > After the relevant versions have been downloaded > to the client (and the repository locks have > been cleared), the merge tools can run > interactively. However, I believe that CVS > current intersperses merges with downloads, and > that would need to change before interactive > merges can be supported. The current CVS operations all occur on the server side prior to downloading patches to the client. What you are suggesting is a fairly major overhaul to the cvs client/server protocol and as such there is probably a 'better' way to deal with this than a 'simple' alternative table of diff3-style programs to do alternative merger algorithms. > Also, CVS currently relies on diff3-style > mark-ups to warn the user when merge conflicts >
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
>--- Forwarded mail from [EMAIL PROTECTED] >Paul Sander <[EMAIL PROTECTED]> writes: >> >--- Forwarded mail from [EMAIL PROTECTED] >>=20 >> Rather than use a hint to expose an >> implementation detail, I suggest recording a >> data type instead. Maybe even a MIME type. Then >> provide a suitable mechanism to map data types >> to tools that are appropriate to the >> environment. >I have no fundamental objection to saving the MIME >type. I suggest that it may need to be inside of a >string to pass the syntax of rcsfile(5). I would >actually suggest that it might be useful to just >borrow both of the MIME media-type and charset >concepts. That might allow for a=20 > "media-type text/plain;" > "charset ks_c_5601-1987;" >on a given file... the defaults should probably >be "text/plain" and iso-8859-1 or utf-8 Do you propose that the media-type be valid on its own, for data types where charsets have no meaning? Or put another way, is the charset solely to provide additional processing hints to supplement the media-type, or is the charset also required? >> >Given that this would appear to be the desire of >> >at least a few folks out there who might want to >> >make CVS do a better job at merging structured >> >ASCII files such as XML or HTML format. And >> >further, that you seem to have objections to this >> >approach. And while I have known you to bring up >> >points I have overlooked in the past... >>=20 >> Not just structured ASCII files as you describe, >> but any file containing structured data for >> which a merge tool is available. >Ahh, but I am not really trying to suggest that >"binary files" are suitable in the general case >for CVS control. That is a separate argument. Fair enough, but the practice is more common than anyone wants to admit. The issue must be faced at some point. >That said, I suppose that a merge utility that >understands how to merge a file containing lines >in a non-ISO-LATIN character set might also fall >into the category of a diff3 replacement and that >such files might be considered 'binary' by some >programs. Indeed. >> >This time around I just do not see anything that >> >would preclude such an approach of using an >> >external diff3 hint 'replacement' program for >> >doing a 'cvs update -jtag1 -jtag2' operation. >>=20 >> >I will stipulate that such a program will likely >> >need to live on the server and furthermore that it >> >would not be interactive. In the absense of >> >finding such a program, CVS would likely resort to >> >using diff3 as a fallback, so its arguments would >> >likely need to match those of the diff3 program >> >itself... at least to the extent that cvs currently >> >uses various arguments to diff3. >>=20 >> I don't believe that such a program MUST live on >> the server. >The changes needed to allow the client-side to do >a merge are very large. I am not willing to >stipulate an implementation that would allow CVS >to deal with an interactive merge operation for a >random 'cvs update' command. The repository would >have a lock open for too long in that case. Yes, to avoid long-lived locks, the necessary files must be copied to the client before the merge begins. This would involve a significant change to the client, but I'm not convinced that it would be a significant change to the server. The server already has the ability to send whole revisions to the client, and it need not be involved with the merge once it starts. >> Merge tools, like editors, have a way of >> becoming religious icons, in situations where >> users have a choice. Under such circumstances, >> it becomes important to have client side >> mappings between data types and merge tools. >Your arguments almost help to make a case in >Greg's favor against allowing a diff3 replacement. Horrors! I sure hope not! :-) >The kind of flexibility you desire is not >something that I think makes sense to bolt into >the 'diff3' slot. Then bolt in a wrapper that reads the user's environment and invokes a suitable merge tool based on preferences that are found there. And provide a default, like diff3, if such information is missing. >What you propose would potentially best be handled >with an entirely new kind of update paradigm. >Possibly the use of a CVS/Base/file file and a >'patch' that would bring CVS/Base/file up to the >latest version would be 'better' in this case... Whatever's most efficient to get the other contributor and common ancestor to the client. Clean-up needs to be considered as well. >> Additionally, I don't believe that merge tools >> necessarily need to be fully automated. >Here we do not agree. Without such automation, >lock contention on directories could get very >intense. Again, running the merge after relevant data have been copied out and freeing the locks would remove this issue. Actually, the ancestor and contributor are checked-in versions, and they're known in advance either by version number or branch/timestamp. Correct me if I'm wrong her
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
[ On Monday, June 28, 2004 at 19:02:19 (-0700), Paul Sander wrote: ] > Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) > > I have never, ever advocated changing the format of an RCS file in a > way that would break the ci, co, rcs, or rlog programs. And although > I strongly advocate the replacement of user-exposed diff and merge > tools, I have never, ever advocated the replacement of the diff tool > that computes the deltas stored in an RCS file. Indeed -- instead you would rather use different algorithms for storing deltas and for using them. That would be just plain stupid, if indeed not eventually dangerous to the integrity of a repository. The tools we now have for calculating and handling deltas are all designed to work _together_, not in isolation of each other, and that uniformity is as valuable to CVS as it is to RCS alone, if not more so. How about you go off and spend the next, say, two years or so intensively using such a scheme as you propose on a massively huge variety of projects. That should give you about 10% of the experience the rest of the world has with using diff and diff3 and rcsmerge uniformly for both purposes. Then if you still think it's wise to use disparate techniques for storing deltas and for using deltas then you can show your results and raise your proposal here again. In the mean time please keep in mind that there are not just a plethora of tools for using diff-style deltas, but there's also an enormous amount of human experience with them too. You (and a few others) seem to want to throw the baby out with the bath water, and all just so that a few hair-brained and lame mis-uses of CVS will work "better". In the mean time if you (and others) had learned to use the best tool for the job in the first place then you'd never have had to dream up such a half-baked idea. -- 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: Smoke, FUD (was Re: CVS corrupts binary files ...)
[ On Tuesday, June 29, 2004 at 02:18:26 (-0700), Paul Sander wrote: ] > Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) > > >I.e. How do you propose to make it possible for the standard RCS tools > >alone to re-create _every_ revision from all files created by this > >hacked system? > > Simple: The delta text would not change. See above. It would be extremely short-sighted, if not downright stupid, to not keep the delta format compatible with that used by the new delta tools. You seem to have no appreciation whatsoever for the depth and breath to which this format (and its easily computed variants) is used and understood. -- 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: Smoke, FUD (was Re: CVS corrupts binary files ...)
[ On Monday, June 28, 2004 at 14:58:03 (-0700), Mark D. Baushke wrote: ] > Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) > > Yes, but diff is not diff3. diff is used for the > delta format. diff3 is used by rcsmerge, not for > fundamental version deltas. I think you're confused -- the differencing algorithms used are fudamentally intertwined (and fundamentally based on units of lines of text). Pretending you can do merges using some other algorithm while still trying to store your deltas in unix diff format is just leading everyone down the garden path to a dark dank corner no-one really wants to be in. The uniform use of differencing algorithms and their corresponding merge algorithms (which are of course just "editing" scripts), is what makes it worthwhile to use something like RCS as the foundation for CVS in the first place. I.e. it is not sufficient to just use the RCS delta format as a means of archive compression -- that format is integral to the whole idea of detecting, reporting, and merging, changes in any RCS-compatible tool. > Are there really utilities out there that try to > to read RCS formats directly and do not allow for > rcsfile(5) syntax to be used? If so, could you > name any of them? Humans, for one. :-) (I know some folks can do manual merges of SCCS files, and though the same techniques won't work quite so well on RCS files because of the reverse delta thing, there are still a great many other valid reasons to read and even repair RCS files by hand.) There are a number of commercial software pacakges which are "GNU RCS compatible", apparently without using RCS source code, with the most "popular" perhaps being CS-RCS (though I've not confirmed 100% that it does not use RCS source code). SourceCodeManager is apparently another, and P4D yet another. Perforce also uses RCS compatible files as its archive format, but I'm not sure if its core RCS handling was derived from RCS source code or not. I think I've just scratched the surface too, if any of the rumours I've heard are close to true. -- 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: Smoke, FUD (was Re: CVS corrupts binary files ...)
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Monday, June 28, 2004 at 19:02:19 (-0700), Paul Sander wrote: ] >> Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) >> >> I have never, ever advocated changing the format of an RCS file in a >> way that would break the ci, co, rcs, or rlog programs. And although >> I strongly advocate the replacement of user-exposed diff and merge >> tools, I have never, ever advocated the replacement of the diff tool >> that computes the deltas stored in an RCS file. >Indeed -- instead you would rather use different algorithms for storing >deltas and for using them. >That would be just plain stupid, if indeed not eventually dangerous to >the integrity of a repository. What are you talking about? I can think of only two ways that CVS "uses" the deltas: Reconstructing complete versions, and annotating version history. For the purposes of this thread, which started out with diffing and merging files, the tools require reconstructed versions. Of course, the algorithms that produce the deltas and reconstruct the original data must agree. But that's all below the RCS API and is completely invisible to the user. Once the user has two or three complete files, he can apply any diff or merge algorithm he wants to those files. Recall the following sequence of operations: co -pancestor file,v > a co -pcontributor file,v > c diff3 -E file a c Once again, the algorithms and data formats that maintain the integrity of the RCS files is hidden away and invisible to the user by way of the co and ci programs. The user can replace the invocation of diff3 with any tool that he chooses to perform the content merge. Once done, the user uses ci to produce a new delta in the RCS files, using the very algorithm that produces the correct data for subsequent invocations of co. There's absolutely no danger to the integrity of the RCS file, unless someone mucks with the innards of co or ci. And nobody is even hinting that making such changes is desirable, at least with respect to the deltatext phrases in the RCS files. (There have been several recommendations to exploit the areas of the rcsfile format that explicitly permit extensions, but extensions of this nature have absolutely no effect on RCS' ability to store and reconstruct versions, which I have demonstrated in a separate message.) >The tools we now have for calculating and handling deltas are all >designed to work _together_, not in isolation of each other, and that >uniformity is as valuable to CVS as it is to RCS alone, if not more so. What tools, specifically (and I mean, you need to name them and include pointers to them so that the rest of us can look), are you talking about? The RCS programs and CVS in its current implementation are the obvious ones, and my comments withstand scrutiny on those. What else are you referring to? >How about you go off and spend the next, say, two years or so >intensively using such a scheme as you propose on a massively huge >variety of projects. That should give you about 10% of the experience >the rest of the world has with using diff and diff3 and rcsmerge >uniformly for both purposes. >Then if you still think it's wise to use disparate techniques for >storing deltas and for using deltas then you can show your results and >raise your proposal here again. >In the mean time please keep in mind that there are not just a plethora >of tools for using diff-style deltas, but there's also an enormous >amount of human experience with them too. I look forward to seeing your list of references, so that we can debate the relative value of interpreting ed-like scripts for a least-common denominator level of functionality, versus parsing the entire content of a reconstructed file and applying domain-specific algorithms that understand the type of data stored there. >You (and a few others) seem to want to throw the baby out with the bath >water, and all just so that a few hair-brained and lame mis-uses of CVS >will work "better". In the mean time if you (and others) had learned to >use the best tool for the job in the first place then you'd never have >had to dream up such a half-baked idea. CVS has a notoriously poor diff and merge capability. Integrating the user-exposed features with better tools is a very good example of using the best tool for the job. And it's not a half-baked idea; the whole idea of plug-ins is well established in the industry, and its feasibility in CVS is proven. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Monday, June 28, 2004 at 14:58:03 (-0700), Mark D. Baushke wrote: ] >> Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) >> >> Yes, but diff is not diff3. diff is used for the >> delta format. diff3 is used by rcsmerge, not for >> fundamental version deltas. >I think you're confused -- the differencing algorithms used are >fudamentally intertwined (and fundamentally based on units of lines of >text). This true, insofar as to maintain the integrity of the RCS files and to reconstruct complete versions. >Pretending you can do merges using some other algorithm while still >trying to store your deltas in unix diff format is just leading everyone >down the garden path to a dark dank corner no-one really wants to be in. What do we care what format the versions are stored in, as long as we can recover the complete files and apply any tool we want to them? Although I can imagine such a thing, I don't know of any merge tool reads the ed-like scripts produced by the diff program and presents a user interface to apply or omit specific deltas to an input file. It's an interesting idea, and it might even be useful, but its utility is limited. On the other hand, reconstructing entire versions and applying content-specific tools is far more useful. For example, there is research on hierarchical differencing algorithms that compare tree-like structures like the ones produced by parsers of programming languages. I foresee that this will lead to a new wave of merge tools that provide a much higher level of utility than line-based tools like diff3. This kind of work just isn't possible with line-based deltas produced by the diff program. (It's also possible that they could lead to a new wave of archivers that provide RCS-like capability but use the hierarchical diffs in the deltatext records, which will be interesting. But nobody's suggesting a possible replacement of the RCS layer just yet.) >The uniform use of differencing algorithms and their corresponding merge >algorithms (which are of course just "editing" scripts), is what makes >it worthwhile to use something like RCS as the foundation for CVS in the >first place. It's what makes it possible for systems like RCS to exploit the similarity of sequential versions for efficient storage, to be sure. But applying a delta to reconstruct a version is very different from doing a content merge of two or three fully reconstructed files. >I.e. it is not sufficient to just use the RCS delta format as a means of >archive compression -- that format is integral to the whole idea of >detecting, reporting, and merging, changes in any RCS-compatible tool. Once again, no one is suggesting changing the way that RCS works. >> Are there really utilities out there that try to >> to read RCS formats directly and do not allow for >> rcsfile(5) syntax to be used? If so, could you >> name any of them? >Humans, for one. :-) >(I know some folks can do manual merges of SCCS files, and though the >same techniques won't work quite so well on RCS files because of the >reverse delta thing, there are still a great many other valid reasons to >read and even repair RCS files by hand.) >There are a number of commercial software pacakges which are "GNU RCS >compatible", apparently without using RCS source code, with the most >"popular" perhaps being CS-RCS (though I've not confirmed 100% that it >does not use RCS source code). SourceCodeManager is apparently another, >and P4D yet another. >Perforce also uses RCS compatible files as its archive format, but I'm >not sure if its core RCS handling was derived from RCS source code or not. >I think I've just scratched the surface too, if any of the rumours I've >heard are close to true. Well, if these tools are truly "RCS compatible" then they should be able to ignore the newphrases we've been talking about. And since there is no proposition to change the format of the deltatext phrases, or any of the other standard components of an RCS file, those tools should continue to work. BTW, I have also written a couple of tools that parse the RCS file syntax. They conform to the rcsfile format and should tolerate extensions made as newphrases as specified. I have also seen commercial tools derived from RCS (specifically, the MKS variety) that have made proprietary extensions and are no longer compatible with the Gnu standard. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
[ On Thursday, July 1, 2004 at 14:33:11 (-0700), Paul Sander wrote: ] > Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) > > What are you talking about? I can think of only two ways that CVS > "uses" the deltas: Well, as usual you got off on the wrong track right from the start again. What part of "RCS Compatible" have you misunderstood this time? > CVS has a notoriously poor diff and merge capability. Well, that seems to depend entirely on your point of view and your perpensity to try to use the wrong (or at least the least suitable) tool for the job. I and no doubt millions of other people have been incredibly satisfied with the extremely wide applicability of the unix diff and merge algorithms. It's almost a miracle that they work so well for such a variety of different kinds of text files -- or maybe it's just an indication of how well designed they are for dealing with the vast majority of forms of representation of human-readable information. Of course you don't have to like them, but you do have to accept that they are integral to RCS and thus integral to CVS. Go away and go play with xdelta and friends if you want. -- 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
