Accidentally merged out code.
Andy Bradford
had copies of the repository (I believe the same). The first person
made changes and committed them. The second person also made changes
and committed them. Then, a third person that supposedly had the same
tree, checked in code and it caused the changes made by person one be
``merged out''. I'm not entirely certain how this could happen since
each did a ``cvs up'' before committing. Person three didn't remove any
code from the files, however, I guess if the code wasn't in there to
begin with then it could have removed it. Would this happen if they
were working on different versions of the same file?
Thanks.
Andy
_______________________________________________
Info-cvs mailing list
Info...@gnu.org
http://mail.gnu.org/mailman/listinfo/info-cvs
Larry Jones
>
> I'm not sure how to describe this situation, but I'll try. Two people
> had copies of the repository (I believe the same). The first person
> made changes and committed them. The second person also made changes
> and committed them. Then, a third person that supposedly had the same
> tree, checked in code and it caused the changes made by person one be
> ``merged out''. I'm not entirely certain how this could happen since
> each did a ``cvs up'' before committing. Person three didn't remove any
> code from the files, however, I guess if the code wasn't in there to
> begin with then it could have removed it. Would this happen if they
> were working on different versions of the same file?
Usually this is caused by someone doing an update while they have a file
loaded into a text editor and then saving the file over top of the
merged version (wiping out the merged changes) and then committing it.
-Larry Jones
What's Santa's definition? How good do you have to be to qualify as good?
-- Calvin
Andy Bradford
> > begin with then it could have removed it. Would this happen if they
> > were working on different versions of the same file?
>
> Usually this is caused by someone doing an update while they have a file
> loaded into a text editor and then saving the file over top of the
> merged version (wiping out the merged changes) and then committing it.
That could be what happened, everyone was in a hurry to get the code
done on time and it is possible that something like this happened. I
believe that they may have maintained a separate tree and then copied
over the files into the CVS tree or something strange like that. I
just want to make sure that it isn't CVS doing something wrong. (Which
I believe it isn't).
Andy
--
[-----------[system uptime]--------------------------------------------]
10:29pm up 41 days, 22:31, 6 users, load average: 1.08, 1.18, 1.14
Harald Kucharek
Andy Bradford wrote:
>
> Thus said Larry Jones on Tue, 27 Mar 2001 16:41:12 EST:
>
> > > begin with then it could have removed it. Would this happen if they
> > > were working on different versions of the same file?
> >
> > Usually this is caused by someone doing an update while they have a file
> > loaded into a text editor and then saving the file over top of the
> > merged version (wiping out the merged changes) and then committing it.
>
> That could be what happened, everyone was in a hurry to get the code
> done on time and it is possible that something like this happened. I
> believe that they may have maintained a separate tree and then copied
> over the files into the CVS tree or something strange like that. I
> just want to make sure that it isn't CVS doing something wrong. (Which
> I believe it isn't).
>
> Andy
Well, I don't think there is any question about it. It can
only be attributable to human error. This sort of thing has
cropped up before, and it has always been due to human
error.
;-) Sorry, I couldn't resist. It's that year...
And, slightly edited:
Let me put it this way, Mr. Bradford. The CVS system is the
most reliable software ever made. No CVS server has ever made
a mistake or distorted information. They are are all, by any practical
definition of the words, foolproof and incapable of error.
;-) Have a nice day.
Harald
--
iXpoint Informationssysteme GmbH #
Daimlerstr. 3 # Harald Kucharek
76275 Ettlingen # Harald....@ixpoint.de
Tel/Fax +49 7243 3775-0/77 # www.ixpoint.de
Andy Bradford
> Well, I don't think there is any question about it. It can
> only be attributable to human error. This sort of thing has
Oh, you won't get any argument from me here...
> Let me put it this way, Mr. Bradford. The CVS system is the
> most reliable software ever made. No CVS server has ever made
> a mistake or distorted information. They are are all, by any practical
> definition of the words, foolproof and incapable of error.
Like I said, I have no qualms with anything you said. I personally
think CVS is truly one of the greatest pieces of software, however,
trying to convince others that have never used it before, that suddenly
attribute all their problems to it, is difficult and I need reasons. I
can't just simply say ``you screwed up.'' I know it's due to human
error, but need to make others see this light. :-)
I understand how CVS works for the most part since I have used RCS,
diff and friends quite extensively, but haven't ever encountered this
situation in my usage (maybe that's because I know how to use it) of
CVS.
Andy
--
[-----------[system uptime]--------------------------------------------]
1:43am up 42 days, 1:46, 4 users, load average: 1.06, 1.06, 1.04
Larry Jones
>
> Let me put it this way, Mr. Bradford. The CVS system is the
> most reliable software ever made. No CVS server has ever made
> a mistake or distorted information. They are are all, by any practical
> definition of the words, foolproof and incapable of error.
I'd feel a lot better about that description if I hadn't just fixed a
bug that could potentially lose the most recent revision(s) of a file.
(Fortunately, there's a very small window of vulnerability and there
haven't been any reports of the problem actually occurring, even though
it's been there for years.)
-Larry Jones
I'm getting disillusioned with these New Years. -- Calvin
Alexander Kamilewicz
>
> Andy Bradford writes:
> >
> > I'm not sure how to describe this situation, but I'll try. Two people
> > had copies of the repository (I believe the same). The first person
> > made changes and committed them. The second person also made changes
> > and committed them. Then, a third person that supposedly had the same
> > tree, checked in code and it caused the changes made by person one be
> > ``merged out''. I'm not entirely certain how this could happen since
> > each did a ``cvs up'' before committing. Person three didn't remove any
> > code from the files, however, I guess if the code wasn't in there to
> > begin with then it could have removed it. Would this happen if they
> > were working on different versions of the same file?
>
> Usually this is caused by someone doing an update while they have a file
> loaded into a text editor and then saving the file over top of the
> merged version (wiping out the merged changes) and then committing it.
LOL!!! That's pretty clever. I hope my developers don't find out about
that....
Alex
Eric Siegerman
> trying to convince others that have never used [CVS] before, that suddenly
> can't just simply say ``you screwed up.'' I know it's due to human
> error, but need to make others see this light. :-)
"cvs history" can be useful. The only time I ever used it was to
prove user error in a case something like this. I can't remember
the details, though; sorry.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. er...@telepres.com
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
Andy Bradford
> > Usually this is caused by someone doing an update while they have a file
> > loaded into a text editor and then saving the file over top of the
> > merged version (wiping out the merged changes) and then committing it.
>
> LOL!!! That's pretty clever. I hope my developers don't find out about
> that....
While it might be clever, it is certainly a nightmare when trying to
figure out why their code disappeared. Then, try explaining to them
that this is not the correct way to use it. :-)
--
[-----------[system uptime]--------------------------------------------]
7:25pm up 42 days, 19:27, 4 users, load average: 1.10, 1.21, 1.10
Alexander Kamilewicz
>
> Thus said "Alexander Kamilewicz" on Wed, 28 Mar 2001 10:24:34 CST:
>
> > > Usually this is caused by someone doing an update while they have a file
> > > loaded into a text editor and then saving the file over top of the
> > > merged version (wiping out the merged changes) and then committing it.
> >
> > LOL!!! That's pretty clever. I hope my developers don't find out about
> > that....
>
> While it might be clever, it is certainly a nightmare when trying to
> figure out why their code disappeared. Then, try explaining to them
> that this is not the correct way to use it. :-)
That's why I've got this large baseball bat here.... :)
--
This message is intended only for the use of the addressee(s) named
herein. The information contained in this message is confidential and
may constitute proprietary or inside information. Unauthorized review,
dissemination, distribution, copying or other use of this message,
including all attachments, is strictly prohibited and may be unlawful.
If you have received this message in error, please notify us immediately
by return e-mail and destroy this message and all copies thereof,
including all attachments.
Laine Stump
> Andy Bradford wrote:
> >
> > Thus said "Alexander Kamilewicz" on Wed, 28 Mar 2001 10:24:34 CST:
> >
> > > > Usually this is caused by someone doing an update while they have a file
> > > > loaded into a text editor and then saving the file over top of the
> > > > merged version (wiping out the merged changes) and then committing it.
> > >
> > > LOL!!! That's pretty clever. I hope my developers don't find out about
> > > that....
> >
> > While it might be clever, it is certainly a nightmare when trying to
> > figure out why their code disappeared. Then, try explaining to them
> > that this is not the correct way to use it. :-)
>
> That's why I've got this large baseball bat here.... :)
And fortunately most text editors (at least the ones I use, ie emacs
and MS Visual Studio) are smart enough to notice when this happens,
and at least give a warning before overwriting the updated copy.
Gianni Mariani
I want to kinda set and forget my cvswrappers file. I have a
mixed Win/unix dev environment and I want to set and forget
which file are binary and which are not.
SO - I created the following cvswrappers file (all ~700 extensions)
that are most likely binary. I got it by scanning my Win drives
for all extensions, running 'file' on them and removing any extensions
which 'file' reported as 'text'.
Any better ideas ? Is this a dumb ass thing to do ?
---- cvswrappers ----
*.386 -k 'b'
*.3GR -k 'b'
*.3gr -k 'b'
*.603 -k 'b'
*.850 -k 'b'
*.852 -k 'b'
*.866 -k 'b'
*.ACG -k 'b'
*.acg -k 'b'
*.ACL -k 'b'
*.acl -k 'b'
*.ACM -k 'b'
*.acm -k 'b'
*.ACS -k 'b'
*.acs -k 'b'
*.ACT -k 'b'
*.act -k 'b'
*.ADP -k 'b'
*.adp -k 'b'
*.ADV -k 'b'
*.adv -k 'b'
*.AFM -k 'b'
*.afm -k 'b'
*.AHQ -k 'b'
*.ahq -k 'b'
*.AIF -k 'b'
*.aif -k 'b'
*.ANI -k 'b'
*.ani -k 'b'
*.AP0 -k 'b'
*.ap0 -k 'b'
*.API -k 'b'
*.api -k 'b'
*.APP -k 'b'
*.app -k 'b'
*.APS -k 'b'
*.aps -k 'b'
*.ATI -k 'b'
*.ati -k 'b'
*.AVB -k 'b'
*.avb -k 'b'
*.AVI -k 'b'
*.avi -k 'b'
*.AW -k 'b'
*.aw -k 'b'
*.AWX -k 'b'
*.awx -k 'b'
*.AX -k 'b'
*.ax -k 'b'
*.AX_ -k 'b'
*.ax_ -k 'b'
*.BDR -k 'b'
*.bdr -k 'b'
*.BFONT -k 'b'
*.bfont -k 'b'
*.BLEND -k 'b'
*.blend -k 'b'
*.BM_ -k 'b'
*.bm_ -k 'b'
*.BMP -k 'b'
*.bmp -k 'b'
*.BS -k 'b'
*.bs -k 'b'
*.BSC -k 'b'
*.bsc -k 'b'
*.BTR -k 'b'
*.btr -k 'b'
*.BX -k 'b'
*.bx -k 'b'
*.BZ2 -k 'b'
*.bz2 -k 'b'
*.CAB -k 'b'
*.cab -k 'b'
*.CAT -k 'b'
*.cat -k 'b'
*.CBD -k 'b'
*.cbd -k 'b'
*.CBK -k 'b'
*.cbk -k 'b'
*.CDR -k 'b'
*.cdr -k 'b'
*.CDX -k 'b'
*.cdx -k 'b'
*.CGM -k 'b'
*.cgm -k 'b'
*.CHI -k 'b'
*.chi -k 'b'
*.CHM -k 'b'
*.chm -k 'b'
*.CHQ -k 'b'
*.chq -k 'b'
*.CHS -k 'b'
*.chs -k 'b'
*.CHT -k 'b'
*.cht -k 'b'
*.CHW -k 'b'
*.chw -k 'b'
*.CL_ -k 'b'
*.cl_ -k 'b'
*.CL4 -k 'b'
*.cl4 -k 'b'
*.CLASS -k 'b'
*.class -k 'b'
*.CLB -k 'b'
*.clb -k 'b'
*.CN_ -k 'b'
*.cn_ -k 'b'
*.CNV -k 'b'
*.cnv -k 'b'
*.COM -k 'b'
*.com -k 'b'
*.CPE -k 'b'
*.cpe -k 'b'
*.CPF -k 'b'
*.cpf -k 'b'
*.CPI -k 'b'
*.cpi -k 'b'
*.CPL -k 'b'
*.cpl -k 'b'
*.CTM -k 'b'
*.ctm -k 'b'
*.CTX -k 'b'
*.ctx -k 'b'
*.CUR -k 'b'
*.cur -k 'b'
*.CW -k 'b'
*.cw -k 'b'
*.DA_ -k 'b'
*.da_ -k 'b'
*.DB1 -k 'b'
*.db1 -k 'b'
*.DBC -k 'b'
*.dbc -k 'b'
*.DBF -k 'b'
*.dbf -k 'b'
*.DBX -k 'b'
*.dbx -k 'b'
*.DCA -k 'b'
*.dca -k 'b'
*.DCF -k 'b'
*.dcf -k 'b'
*.DCR -k 'b'
*.dcr -k 'b'
*.DCT -k 'b'
*.dct -k 'b'
*.DCX -k 'b'
*.dcx -k 'b'
*.DE_ -k 'b'
*.de_ -k 'b'
*.DEL -k 'b'
*.del -k 'b'
*.DESKLINK -k 'b'
*.desklink -k 'b'
*.DF_ -k 'b'
*.df_ -k 'b'
*.DFT -k 'b'
*.dft -k 'b'
*.DIB -k 'b'
*.dib -k 'b'
*.DIL -k 'b'
*.dil -k 'b'
*.DIR -k 'b'
*.dir -k 'b'
*.DL_ -k 'b'
*.dl_ -k 'b'
*.DLG -k 'b'
*.dlg -k 'b'
*.DLL -k 'b'
*.dll -k 'b'
*.DLS -k 'b'
*.dls -k 'b'
*.DOC -k 'b'
*.doc -k 'b'
*.DOT -k 'b'
*.dot -k 'b'
*.DOX -k 'b'
*.dox -k 'b'
*.DR_ -k 'b'
*.dr_ -k 'b'
*.DRV -k 'b'
*.drv -k 'b'
*.DS -k 'b'
*.ds -k 'b'
*.DS_ -k 'b'
*.ds_ -k 'b'
*.DSK -k 'b'
*.dsk -k 'b'
*.DST -k 'b'
*.dst -k 'b'
*.DSX -k 'b'
*.dsx -k 'b'
*.DSZ -k 'b'
*.dsz -k 'b'
*.DTQ -k 'b'
*.dtq -k 'b'
*.DWR -k 'b'
*.dwr -k 'b'
*.EBX -k 'b'
*.ebx -k 'b'
*.ECW -k 'b'
*.ecw -k 'b'
*.ELM -k 'b'
*.elm -k 'b'
*.EMF -k 'b'
*.emf -k 'b'
*.EN_ -k 'b'
*.en_ -k 'b'
*.ENU -k 'b'
*.enu -k 'b'
*.ENV -k 'b'
*.env -k 'b'
*.EPS -k 'b'
*.eps -k 'b'
*.ERO -k 'b'
*.ero -k 'b'
*.ES_ -k 'b'
*.es_ -k 'b'
*.EWL -k 'b'
*.ewl -k 'b'
*.EX_ -k 'b'
*.ex_ -k 'b'
*.EXD -k 'b'
*.exd -k 'b'
*.EXE -k 'b'
*.exe -k 'b'
*.EXP -k 'b'
*.exp -k 'b'
*.FAE -k 'b'
*.fae -k 'b'
*.FAV -k 'b'
*.fav -k 'b'
*.FCS -k 'b'
*.fcs -k 'b'
*.FIL -k 'b'
*.fil -k 'b'
*.FLL -k 'b'
*.fll -k 'b'
*.FLT -k 'b'
*.flt -k 'b'
*.FNT -k 'b'
*.fnt -k 'b'
*.FON -k 'b'
*.fon -k 'b'
*.FPT -k 'b'
*.fpt -k 'b'
*.FPX -k 'b'
*.fpx -k 'b'
*.FR_ -k 'b'
*.fr_ -k 'b'
*.FRT -k 'b'
*.frt -k 'b'
*.FRX -k 'b'
*.frx -k 'b'
*.FTG -k 'b'
*.ftg -k 'b'
*.FTS -k 'b'
*.fts -k 'b'
*.GID -k 'b'
*.gid -k 'b'
*.GIF -k 'b'
*.gif -k 'b'
*.GPD -k 'b'
*.gpd -k 'b'
*.GPT -k 'b'
*.gpt -k 'b'
*.GRA -k 'b'
*.gra -k 'b'
*.GRF -k 'b'
*.grf -k 'b'
*.GZ -k 'b'
*.gz -k 'b'
*.HDR -k 'b'
*.hdr -k 'b'
*.HL_ -k 'b'
*.hl_ -k 'b'
*.HLP -k 'b'
*.hlp -k 'b'
*.HLX -k 'b'
*.hlx -k 'b'
*.HT -k 'b'
*.ht -k 'b'
*.ICM -k 'b'
*.icm -k 'b'
*.ICO -k 'b'
*.ico -k 'b'
*.ID -k 'b'
*.id -k 'b'
*.IDB -k 'b'
*.idb -k 'b'
*.IDF -k 'b'
*.idf -k 'b'
*.ILG -k 'b'
*.ilg -k 'b'
*.ILK -k 'b'
*.ilk -k 'b'
*.IN_ -k 'b'
*.in_ -k 'b'
*.IND -k 'b'
*.ind -k 'b'
*.INS -k 'b'
*.ins -k 'b'
*.INX -k 'b'
*.inx -k 'b'
*.ISU -k 'b'
*.isu -k 'b'
*.IT_ -k 'b'
*.it_ -k 'b'
*.JAR -k 'b'
*.jar -k 'b'
*.JOB -k 'b'
*.job -k 'b'
*.JP_ -k 'b'
*.jp_ -k 'b'
*.JPEG -k 'b'
*.jpeg -k 'b'
*.JPG -k 'b'
*.jpg -k 'b'
*.KBD -k 'b'
*.kbd -k 'b'
*.KO_ -k 'b'
*.ko_ -k 'b'
*.LAN -k 'b'
*.lan -k 'b'
*.LBT -k 'b'
*.lbt -k 'b'
*.LBX -k 'b'
*.lbx -k 'b'
*.LCK -k 'b'
*.lck -k 'b'
*.LEX -k 'b'
*.lex -k 'b'
*.LGS -k 'b'
*.lgs -k 'b'
*.LIB -k 'b'
*.lib -k 'b'
*.LNK -k 'b'
*.lnk -k 'b'
*.LXA -k 'b'
*.lxa -k 'b'
*.LZZZZZZZ -k 'b'
*.lzzzzzzz -k 'b'
*.M20 -k 'b'
*.m20 -k 'b'
*.M2V -k 'b'
*.m2v -k 'b'
*.MAPIMAIL -k 'b'
*.mapimail -k 'b'
*.MCH -k 'b'
*.mch -k 'b'
*.MDA -k 'b'
*.mda -k 'b'
*.MDB -k 'b'
*.mdb -k 'b'
*.MDE -k 'b'
*.mde -k 'b'
*.MDP -k 'b'
*.mdp -k 'b'
*.MDT -k 'b'
*.mdt -k 'b'
*.MDW -k 'b'
*.mdw -k 'b'
*.MDZ -k 'b'
*.mdz -k 'b'
*.MEM -k 'b'
*.mem -k 'b'
*.MFD -k 'b'
*.mfd -k 'b'
*.MFM -k 'b'
*.mfm -k 'b'
*.MID -k 'b'
*.mid -k 'b'
*.MM -k 'b'
*.mm -k 'b'
*.MMC -k 'b'
*.mmc -k 'b'
*.MMM -k 'b'
*.mmm -k 'b'
*.MNT -k 'b'
*.mnt -k 'b'
*.MNX -k 'b'
*.mnx -k 'b'
*.MOD -k 'b'
*.mod -k 'b'
*.MPD -k 'b'
*.mpd -k 'b'
*.MPEG -k 'b'
*.mpeg -k 'b'
*.MPT -k 'b'
*.mpt -k 'b'
*.MRG -k 'b'
*.mrg -k 'b'
*.MSC -k 'b'
*.msc -k 'b'
*.MSG -k 'b'
*.msg -k 'b'
*.MSI -k 'b'
*.msi -k 'b'
*.MSK -k 'b'
*.msk -k 'b'
*.MSO -k 'b'
*.mso -k 'b'
*.MTS -k 'b'
*.mts -k 'b'
*.MTZ -k 'b'
*.mtz -k 'b'
*.NCB -k 'b'
*.ncb -k 'b'
*.NICK -k 'b'
*.nick -k 'b'
*.NL_ -k 'b'
*.nl_ -k 'b'
*.NLM -k 'b'
*.nlm -k 'b'
*.NLQ -k 'b'
*.nlq -k 'b'
*.NLS -k 'b'
*.nls -k 'b'
*.NSC -k 'b'
*.nsc -k 'b'
*.OBJ -k 'b'
*.obj -k 'b'
*.OCA -k 'b'
*.oca -k 'b'
*.OCX -k 'b'
*.ocx -k 'b'
*.OFT -k 'b'
*.oft -k 'b'
*.OLB -k 'b'
*.olb -k 'b'
*.OPT -k 'b'
*.opt -k 'b'
*.OUT -k 'b'
*.out -k 'b'
*.PA -k 'b'
*.pa -k 'b'
*.PAL -k 'b'
*.pal -k 'b'
*.PCH -k 'b'
*.pch -k 'b'
*.PCI -k 'b'
*.pci -k 'b'
*.PCX -k 'b'
*.pcx -k 'b'
*.PDB -k 'b'
*.pdb -k 'b'
*.PDF -k 'b'
*.pdf -k 'b'
*.PDR -k 'b'
*.pdr -k 'b'
*.PEN -k 'b'
*.pen -k 'b'
*.PFB -k 'b'
*.pfb -k 'b'
*.PFM -k 'b'
*.pfm -k 'b'
*.PIF -k 'b'
*.pif -k 'b'
*.PIP -k 'b'
*.pip -k 'b'
*.PJT -k 'b'
*.pjt -k 'b'
*.PJX -k 'b'
*.pjx -k 'b'
*.PKG -k 'b'
*.pkg -k 'b'
*.PLT -k 'b'
*.plt -k 'b'
*.PM -k 'b'
*.pm -k 'b'
*.PNF -k 'b'
*.pnf -k 'b'
*.PNG -k 'b'
*.png -k 'b'
*.POT -k 'b'
*.pot -k 'b'
*.PPA -k 'b'
*.ppa -k 'b'
*.PPD -k 'b'
*.ppd -k 'b'
*.PPM -k 'b'
*.ppm -k 'b'
*.PPT -k 'b'
*.ppt -k 'b'
*.PRF -k 'b'
*.prf -k 'b'
*.PRN -k 'b'
*.prn -k 'b'
*.PRX -k 'b'
*.prx -k 'b'
*.PSD -k 'b'
*.psd -k 'b'
*.PST -k 'b'
*.pst -k 'b'
*.PT_ -k 'b'
*.pt_ -k 'b'
*.PUB -k 'b'
*.pub -k 'b'
*.PVK -k 'b'
*.pvk -k 'b'
*.PWL -k 'b'
*.pwl -k 'b'
*.RCT -k 'b'
*.rct -k 'b'
*.RES -k 'b'
*.res -k 'b'
*.RESOURCES -k 'b'
*.resources -k 'b'
*.RMI -k 'b'
*.rmi -k 'b'
*.ROB -k 'b'
*.rob -k 'b'
*.RPM -k 'b'
*.rpm -k 'b'
*.RSC -k 'b'
*.rsc -k 'b'
*.RSD -k 'b'
*.rsd -k 'b'
*.RTF -k 'b'
*.rtf -k 'b'
*.RUL -k 'b'
*.rul -k 'b'
*.SCR -k 'b'
*.scr -k 'b'
*.SCT -k 'b'
*.sct -k 'b'
*.SCX -k 'b'
*.scx -k 'b'
*.SDB -k 'b'
*.sdb -k 'b'
*.SEO -k 'b'
*.seo -k 'b'
*.SF0 -k 'b'
*.sf0 -k 'b'
*.SFC -k 'b'
*.sfc -k 'b'
*.SGF -k 'b'
*.sgf -k 'b'
*.SHW -k 'b'
*.shw -k 'b'
*.SKN -k 'b'
*.skn -k 'b'
*.SLL -k 'b'
*.sll -k 'b'
*.SMP -k 'b'
*.smp -k 'b'
*.SPC -k 'b'
*.spc -k 'b'
*.SPD -k 'b'
*.spd -k 'b'
*.SPF -k 'b'
*.spf -k 'b'
*.SQP -k 'b'
*.sqp -k 'b'
*.STC -k 'b'
*.stc -k 'b'
*.STR -k 'b'
*.str -k 'b'
*.SUO -k 'b'
*.suo -k 'b'
*.SV_ -k 'b'
*.sv_ -k 'b'
*.SWA -k 'b'
*.swa -k 'b'
*.SWF -k 'b'
*.swf -k 'b'
*.SWP -k 'b'
*.swp -k 'b'
*.SY_ -k 'b'
*.sy_ -k 'b'
*.SY0 -k 'b'
*.sy0 -k 'b'
*.SYD -k 'b'
*.syd -k 'b'
*.SYN -k 'b'
*.syn -k 'b'
*.SYS -k 'b'
*.sys -k 'b'
*.SYSK -k 'b'
*.sysk -k 'b'
*.TBD -k 'b'
*.tbd -k 'b'
*.TBK -k 'b'
*.tbk -k 'b'
*.TDF -k 'b'
*.tdf -k 'b'
*.TGZ -k 'b'
*.tgz -k 'b'
*.TIF -k 'b'
*.tif -k 'b'
*.TLB -k 'b'
*.tlb -k 'b'
*.TRE -k 'b'
*.tre -k 'b'
*.TSC -k 'b'
*.tsc -k 'b'
*.TSK -k 'b'
*.tsk -k 'b'
*.TSP -k 'b'
*.tsp -k 'b'
*.TTF -k 'b'
*.ttf -k 'b'
*.TUW -k 'b'
*.tuw -k 'b'
*.TWD -k 'b'
*.twd -k 'b'
*.VAL -k 'b'
*.val -k 'b'
*.VAM -k 'b'
*.vam -k 'b'
*.VBD -k 'b'
*.vbd -k 'b'
*.VBX -k 'b'
*.vbx -k 'b'
*.VCE -k 'b'
*.vce -k 'b'
*.VCT -k 'b'
*.vct -k 'b'
*.VCX -k 'b'
*.vcx -k 'b'
*.VEC -k 'b'
*.vec -k 'b'
*.VJP -k 'b'
*.vjp -k 'b'
*.VSD -k 'b'
*.vsd -k 'b'
*.VSK -k 'b'
*.vsk -k 'b'
*.VWP -k 'b'
*.vwp -k 'b'
*.VX_ -k 'b'
*.vx_ -k 'b'
*.VXD -k 'b'
*.vxd -k 'b'
*.WAV -k 'b'
*.wav -k 'b'
*.WB2 -k 'b'
*.wb2 -k 'b'
*.WBK -k 'b'
*.wbk -k 'b'
*.WBM -k 'b'
*.wbm -k 'b'
*.WEB -k 'b'
*.web -k 'b'
*.WIZ -k 'b'
*.wiz -k 'b'
*.WK4 -k 'b'
*.wk4 -k 'b'
*.WMF -k 'b'
*.wmf -k 'b'
*.WND -k 'b'
*.wnd -k 'b'
*.WPC -k 'b'
*.wpc -k 'b'
*.WPD -k 'b'
*.wpd -k 'b'
*.WPG -k 'b'
*.wpg -k 'b'
*.WPX -k 'b'
*.wpx -k 'b'
*.WRI -k 'b'
*.wri -k 'b'
*.X04 -k 'b'
*.x04 -k 'b'
*.X06 -k 'b'
*.x06 -k 'b'
*.X32 -k 'b'
*.x32 -k 'b'
*.XLA -k 'b'
*.xla -k 'b'
*.XLB -k 'b'
*.xlb -k 'b'
*.XLL -k 'b'
*.xll -k 'b'
*.XLM -k 'b'
*.xlm -k 'b'
*.XLS -k 'b'
*.xls -k 'b'
*.XLT -k 'b'
*.xlt -k 'b'
*.YBK -k 'b'
*.ybk -k 'b'
*.ZIP -k 'b'
*.zip -k 'b'
Rob Helmer
Well, I won't ask why you want ot check any of this stuff into
CVS ;)
You can just do this :
*.[Dd][Oo][Cc]
to cover all possible capitalizations of .doc files, for instance.
HTH,
Rob Helmer
Eric Siegerman
> that are most likely binary. I got it by scanning my Win drives
> for all extensions, running 'file' on them and removing any extensions
> which 'file' reported as 'text'.
I've seen extensions that are sometimes binary, sometimes text
(eg. MS uses it for some specific binary format, but some
freeware packages use it for text). Can't remember offhand what
they were; maybe *.inf?
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. er...@telepres.com
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
_______________________________________________
Gianni Mariani
I've had a number of suggestions below to do a more complete coverage of
cvswrappers.
Thanks to all who have responded, I have attached my cvswrappers file -
consider it public domain. *<STANDARD DISCLAIMER>* ... I take no
responsibility yadda yadda, it IS YOUR FAULT if it breaks your files, melts
your computer, wastes your time or money and does unpleasant things yadda
yadda and it probably will yadda.*</STANDARD DISCLAIMER>*
As to Rob's question below, the answer is 'I have no idea and I don't want
to think about it - too much'. So I figure it's best to spend 20 minutes
making an all encompasing cvswrappers file and if someone forgets to
remember to do a "cvs add -kb" then I might just have saved myself 20
minutes of fussing.
Turns out that I have already run into this problem - even in a *nix
environment with someone checking in a tgz file and it getting munged, and
then later in another company when they checked in a bunch o MSVS projects
and WAV, BMP and a bunch o files, I just don't remember the extension of,
which broke. So this time it's a pre-emptive strike - although I will still
be bitten - I know I will, it will probably less frequently.
I would actually call this a major deficiency in CVS - it should probably
assume binary by default, or even use the command 'file' to detect the file
type on adding a file. Destroying files by default is just not recomended 10
out of 10 times - just at a guess.
I rant ...
Good evening - sweet dreams ....
G
Greg A. Woods
> Subject: RE: cvswrappers - any better suggestions ?
>
> I would actually call this a major deficiency in CVS - it should probably
> assume binary by default, or even use the command 'file' to detect the file
> type on adding a file. Destroying files by default is just not recomended 10
> out of 10 times - just at a guess.
WHOA! Hold on just a moment here!
"CVS" is the "Concurrent Versions System". It was explicitly and
knowingly designed to handle *concurrent* editing of *source* code
(i.e. the stuff that's logically mergable with diff3)! Versions of
binaries files are, by definition, not possible to merge in any logical
way with diff3, ergo CVS does not deal with binary file formats.
This cvswrappers crap was a poorly thought out add-on that does not do
very much good for anyone and which tries its damndest to go against the
core design of CVS from the inside out. If you use it without fully
understanding the implications then you only get what you deserve.
If CVS destroys binary files by default then that's OK because storing
binary files in CVS in the first place is a user error -- it's not
designed to handle them in any complete way whatsoever. RTFM.
If you want some kind of file and versioning management tool that has
some of the characteristics and features of CVS (eg. the user interface,
and/or the remote access protocol) then write such a tool -- just don't
call it CVS.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
Gianni Mariani
Greg,
Your point is well taken. However, time are a changing - source code is not
only text. Image, sound, movie, geometry, encryption key, etc etc files are
all parts of modern day applications. All these files need to be version
managed just like regular files. If we could apply an rcsmerge on these
kinds of files, then it would be ideal.
Here is some interesting work in this area:
http://www.cs.berkeley.edu/~jmacd/xdelta.html
I have one idea that might work. Earlier versions of RCS used to not deal
with binary files at all. At that time, people used to uuencode or base64
encode binary files and then check them into RCS files. Under some
circumstances these files are mergable and hence limited "concurrent"
modification is possible. I can think of at least 2 generic ways that you
could encode binary files into text files that could in many cases enable
merging of modifications - now, if they would break the intended
applications or not is a different story, but it would be easy to back out a
change and restore the original unlike today.
We both agree, cvswrappers is a band aid at best.
As to the RTFM comment, I have. Not all the users in my company have. I
don't want everyone to have to spend days understanding the ins and outs of
CVS like I have. I want it to just work - ALL the time. Hence, if someone
checks in binary files, then it should not have a default action of
destroying the file. Most files that are mergable have well known
extensions, "cpp", "c", "h", "java" etc and the 'file' command does a good
job of identifying them as "text". Version management goes beyond just text
files.
As to MYSELF developing a new versions management system, there are plenty
of people doing that, I would just confuse the situation. The reason I
choose CVS is because it is prolific, people I hire are likely going to know
about the system. I'd rather fix CVS itself - that is if I get time to do
it - along with my 100 other unfinished projects.
My suggestion to you, as you offered so many to me, is to think about a
broader use of CVS as not only a concurrent versions/merging tool but also
as a database off all components that are used to build products - some of
which are not text; that I need to version successfully and satisfies the
ACID semantics (Atomicity, Consistency, Isolation, and Durability). Then
add this to an environment of many users that have very different levels of
expertise. I assert that people who do default things should not have
surprises - especially damaged data - even if the default thing (like adding
a new file without explicity saying it is binary) is a dumb thing to do.
Thanks
G
-----Original Message-----
From: wo...@proven.weird.com [mailto:wo...@proven.weird.com]On Behalf Of
Greg A. Woods
Sent: Thursday, March 29, 2001 11:52 PM
To: Gianni Mariani
Cc: info...@gnu.org
Greg A. Woods
> Subject: RE: cvswrappers - any better suggestions ?
>
> only text. Image, sound, movie, geometry, encryption key, etc etc files are
> all parts of modern day applications. All these files need to be version
> managed just like regular files. If we could apply an rcsmerge on these
> kinds of files, then it would be ideal.
Yes, what you say is all very well and fine. What it means though is
that CVS is not the correct tool for use in such a diverse environment.
Obviously my point did not sink in properly though so I will say it more
clearly: PLEASE go use something else!!!!
> Here is some interesting work in this area:
> http://www.cs.berkeley.edu/~jmacd/xdelta.html
Yes, and I was aware of it well before most of the rest of the community
was, but CVS does not xdelta, and in fact cannot without breaking it's
current design goal of keeping the repository fully RCS compatible.
(note that even though RCS can store binary files, CVS cannot deal
properly with RCS'ed binary files in its repository. CVS runs on top of
RCS, not the other way around!)
> We both agree, cvswrappers is a band aid at best.
No, if that's what you think then we do not agree. Cvswrappers are a
mistake that misleads users into thinking CVS is something that it just
cannot be. They can only cause problems. They should never ever have
been added to the "official" release. They should in fact be removed
before the next major release is made, if indeed anyone ever gets brave
enough tot make a "major" release. If some poor user can't find a way
to do without them or to use some other more appropriate tool then that
user is free to maintain his or her own local version of CVS with them
still integrated, and since CVS is free software that user is free to
make either the patches or the integrated release freely available too.
> As to MYSELF developing a new versions management system, there are plenty
> of people doing that, I would just confuse the situation.
If you were to build a tool that filled your needs explicitly, and then
freely offered it to the world, just as the authors of CVS and CVS-II
originally did, then perhaps you'd clarify things.
If not then perhaps you should become an early adopter of whichever of
these other new systems you think will in fact actually meet your
explicit requirements.
> The reason I
> choose CVS is because it is prolific, people I hire are likely going to know
> about the system. I'd rather fix CVS itself - that is if I get time to do
> it - along with my 100 other unfinished projects.
Then you chose CVS for exactly the wrong reasons and as a result you
made the wrong choice because you ignored the fact that it does not meet
your real requirements.
CVS is not something that tries to gain market share at all costs --
quite the opposite as it is free software that very nicely and properly
fills *one* niche in the software configuration management tool set.
Because it is free software you are free to mis-use it, but you'd be
better off realising that you're also free not to use it at all.
Choosing CVS because you percieve that it has market share despite the
fact that it obviously does not meet your real requirements demonstrates
that you do not understand how to make effective use of free software!
Demanding that CVS properly handle binary files either demonstrates that
you do not understand your own requirements or you do not understand the
goals of free software and the reasons why a tool like CVS would be made
freely available.
> My suggestion to you, as you offered so many to me, is to think about a
> broader use of CVS as not only a concurrent versions/merging tool but also
> as a database off all components that are used to build products
Excuse me, but CVS is not anything but a *source* code control tool that
was *explicitly* designed to support, nay to force, the ability for its
users to concurrently edit source files!
Anyone who tries to use it for something else, will inevitably run into
problems such as you have.
> - some of
> which are not text; that I need to version successfully and satisfies the
> ACID semantics (Atomicity, Consistency, Isolation, and Durability).
Then you absolutely need something that is not CVS. Period.
Gianni Mariani
> To: Gianni Mariani
.
.
.
> Obviously my point did not sink in properly though so I will say it more
> clearly: PLEASE go use something else!!!!
We clearly violently disagree, obviously there is no point in further
discussion.
Cheers
G
David Glick
With the proliferation of MSWord, IDE project files, etc, no reasonable person can argue that non-text files are not a necessary part of most projects these days. If CVS does not 'grow up' and attempt to support the new development environments, it will slowly be replaced by something that does, and CVS will ultimately become a bit player, promoted by a few fanatic users who try to make its case at every opportunity (whether appropriate or not), and ignored or laughed at by the majority of the population.
I've heard your same arguments applied to Forth, OS/2, Geos, Clarion, Lotus 1-2-3, Wordstar, UCSD P-System... the list goes on. I'd hate to add CVS to the list.
David Glick
Transmit Consulting, Inc
619-475-4052
dgl...@home.com
----- Original Message -----
<--- snip --->
[ On Friday, March 30, 2001 at 07:07:14 (-0800), Gianni Mariani wrote: ]
> Subject: RE: cvswrappers - any better suggestions ?
>
> Your point is well taken. However, time are a changing - source code is not
> only text. Image, sound, movie, geometry, encryption key, etc etc files are
> all parts of modern day applications. All these files need to be version
> managed just like regular files. If we could apply an rcsmerge on these
> kinds of files, then it would be ideal.
Yes, what you say is all very well and fine. What it means though is
that CVS is not the correct tool for use in such a diverse environment.
Obviously my point did not sink in properly though so I will say it more
clearly: PLEASE go use something else!!!!
<--- /snip --->
Greg A. Woods
> Subject: RE: cvswrappers - any better suggestions ?
>
> points which CVS will need to address if it is to survive. I'm an
> independent consultant, and I try to bring CVS into each organization
> I work with. I'm sometimes successful, but I fail at times for
> exactly the reasons Gianni articulates.
Come on you guys!!!! CVS's goal is not to "survive", whatever the heck
that could possibly mean in a free software community!!!!! Survival and
market share are not just oxymorons to free software, but in fact are
dangerous concepts that can only damage good free software (look at the
horrible mess in things like Mozilla, KDE, and even most GNU/Linux
distributions!).
The goal of CVS is to to *exactly* what it does and has always done!!!!
That's it. Nothing more. Nothing less.
CVS will survive in exactly the places where it fulfills the
requirements it was designed to fulfill. If those requirements ever
completely go away, or if any other tool comes along that fulfills those
requirements in an obviously better way, then maybe CVS will cease to
"survive", but that'll be a good thing and we'll all rejoice when it
happens!
If you put CVS into organisations where it won't do anything but confuse
them and cause them troubles because it's the wrong tool for their
requirements then you're doing the WRONG thing! It's no damn wonder
that sometimes you fail to convince some clients to use CVS! They don't
all NEED it!!!! You fail in those cases because you have failed to
understand their requirements and to correctly do the job they hired you
to do!
PLEASE learn to understand your requirements and learn to use the right
tool for the right job. You do not use a hammer to turn in screws and
you do not modify your hammer to make it look like a screwdriver because
if you do then you won't have a hammer any more!
You've got absolutely NO excuse for using the wrong FREE tools!!!!!!
We do NOT need any false CVS evangelists who preach it as a hammer for
all screws!!!! It is already a monopoly in the niche it fits in, and if
you can't figure out what niche that is then don't evangelise it (and
you probably shouldn't even use it either)!
(and yes I do use Mozilla -- it's the best free software of its type
that I've been able to find and it fills more of my requirements than
anything else like it)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
_______________________________________________
Gianni Mariani
Greg,
We heard you already - we just don't agree with you. There is very little
point saying the same thing over again.
<rant type=philosophical disposition="ignore if uninterested">
WE (TM) (the philosophical WE) each have our different goals, there is
absolutly no reason for them to be the same and MANY reasons for them to
be different.
Your discussion below exposes a perspective which is about as far off from
my own as you can get. I will go as far to say that your goals are very
different to most that are using CVS today. I will stretch even further
and say that there are about as many different goals users have for CVS
as there are CVS users.
So, when YOU (TM) (the philosphical YOU) find everyone else is doing
the Wrong Thing (TM) you might find it fruitless and more often negative
to convince THEM (TM) otherwise. A more productive approach may be to
accept that THEY (TM) are just different. It does not mean you have to
agree with THEM (TM). It does mean however you stop arguing with once
THEY (TM) acknowledge and reject your point of view.
</rant>
BESTOLUCK
G
-----Original Message-----
From: info-cv...@gnu.org [mailto:info-cv...@gnu.org]On Behalf Of
Greg A. Woods
Greg A. Woods
> Subject: RE: cvswrappers - any better suggestions ?
>
> my own as you can get. I will go as far to say that your goals are very
> different to most that are using CVS today. I will stretch even further
> and say that there are about as many different goals users have for CVS
> as there are CVS users.
You people just don't get it. CVS adheres to design principles that are
completely contrary to your requirements. You CANNOT succeed with it
given your current goals! It's irrelevant how many users have made the
wrong choice and are using CVS despite the fact that its design is
contrary to their goals. A wrong choice is wrong no matter which side
you look at it from.
Please go find some other software to abuse, and hopefully this time
you'll choose some non-free software and you'll be able to pay it's
maintainers to change their design if it doesn't happen to fit your
goals! Maybe you'll be lucky and you'll choose some non-free software
that has a significant "market share" too.
David Glick
BTW, I *do* get it; I just don't agree with you. I've spent most of 20+ years listening to people just like you explain why something shouldn't/couldn't be done, and then finding ways to make it happen anyway. Clearly, other people feel the same way, because CVS does support binary files after a fashion. I just want them supported better.
Because I respect someone as certain of themselves as you are (even if you're wrong), I'll let you know what the answer is when I find it.
David Glick
Transmit Consulting, Inc
619-475-4052
dgl...@home.com
----- Original Message -----
--
Greg A. Woods
Peter Ring
chosen by CVS, much as you get chosen by Microsoft operating systems and
development tools, simply because it's ubiquitous. Like it or not, there's
not much respect for original design goals in the ways of the world.
I suppose that 'full RCS compatibility' is not a goal by itself -- if you
might as well use RCS, then why use CVS?
I'd like to bring attention to one particular offspring of cvs: subversion.
Have a look at http://subversion.tigris.org/. The project is near it's
second major milestone, and plan to have an alpha release mid May and a 1.0
release late June.
BTW, here's another way to use currently available features (aka
cvswrappers) to avoid the poor loosers munging their binary files: Rather
that listing patterns for known 'binary' files, you list patterns for known
'text' files, but default to binary, like this:
# text formats
*.[Tt][Xx][Tt]
*.[Xx][Mm]][Ll]
*.[Cc]
#default is binary
* -k 'b'
Remember that cvswrappers doesn't work if you connect to the repository
using a remote protocol (e.g. pserver); you must put a copy of the
'cvswrappers' file named '.cvswrappers' into each users home directory.
Kind regards
Peter Ring
-----Original Message-----
From: info-cv...@gnu.org [mailto:info-cv...@gnu.org]On Behalf Of
Greg A. Woods
Sent: Saturday, 31 March, 2001 2:19 AM
To: Gianni Mariani
Cc: info...@gnu.org
Subject: RE: cvswrappers - any better suggestions ?
[ On Friday, March 30, 2001 at 07:07:14 (-0800), Gianni Mariani wrote: ]
> Subject: RE: cvswrappers - any better suggestions ?
>
> Your point is well taken. However, time are a changing - source code is
not
> only text. Image, sound, movie, geometry, encryption key, etc etc files
are
> all parts of modern day applications. All these files need to be version
> managed just like regular files. If we could apply an rcsmerge on these
> kinds of files, then it would be ideal.
Yes, what you say is all very well and fine. What it means though is
that CVS is not the correct tool for use in such a diverse environment.
Obviously my point did not sink in properly though so I will say it more
clearly: PLEASE go use something else!!!!
<snip>
David H. Thornley
"Greg A. Woods" wrote:
>
> [ On Sunday, April 1, 2001 at 08:26:32 (-0800), Gianni Mariani wrote: ]
> > Subject: RE: cvswrappers - any better suggestions ?
> >
> > Your discussion below exposes a perspective which is about as far off from
> > my own as you can get. I will go as far to say that your goals are >
> You people just don't get it. CVS adheres to design principles that are
> completely contrary to your requirements. You CANNOT succeed with it
> given your current goals! It's irrelevant how many users have made the
> wrong choice and are using CVS despite the fact that its design is
> contrary to their goals. A wrong choice is wrong no matter which side
> you look at it from.
>
Nope; CVS adheres to design principles that are at least somewhat
compatible with our requirements. The fact that people are using
CVS for the management of binary files implies that somebody can
do it and be successful. Nor do I understand why this is inherently
a wrong choice. I can understand why it would be the wrong choice
under some given circumstances, but I have a great deal of difficulty
with moral absolutes in open-source software.
> Please go find some other software to abuse, and hopefully this time
> you'll choose some non-free software and you'll be able to pay it's
> maintainers to change their design if it doesn't happen to fit your
> goals! Maybe you'll be lucky and you'll choose some non-free software
> that has a significant "market share" too.
>
Philosophically, this seems to be a Platonist approach to
software tools, and you're in a community of Aristotelians.
What this means is that I believe we don't have archetypes of
programming tools, in which CVS is judged on its similarity
to the archetype of program source control systems, but a whole
lot of existing tools, which are judged on certain criteria
(philosophically more accidental than essential) such as usefulness.
I apply this sort of philosophy for other tools, also. I don't
wonder about how screwdrivery a screwdriver is, but rather how
easily it turns screws and how durable it's likely to be. Given
a paint can, I don't go to the hardware store and buy a tool
to open paint cans, I pry off the lid with a screwdriver. It
isn't designed to open paint cans, is not intended to, and is not
sold for the purpose. I would assume it's harder to remove a
lid without bending it with a screwdriver than with a specially
designed tool (with a screwdriver, you have to pry gently around
the lid). However, I have screwdrivers and a place to put them.
I don't want to buy and store a special paint can lid opening
tool.
Heck, I don't even want to write to tool manufacturers and tell
them that they need to make screwdrivers more paint-can-lid
compatible.
--
David H. Thornley Software Engineer
at CES International, Inc.: David.T...@ces.com or (763)-694-2556
at home: (612)-623-0552 or da...@thornley.net or
http://www.visi.com/~thornley/david/
Gianni Mariani
Peter, you say: "Remember that cvswrappers doesn't work if you connect to
the repository using a remote protocol (e.g. pserver); you must put a copy
of the
'cvswrappers' file named '.cvswrappers' into each users home directory."
I have evidence to the contrary. I just tested it using :pserver: .
BTW - I love the default binary cvswrappers. That is exactly what I was
looking for. I should have figured that out sooner, it's obvious. I would
like the file check before checking in though !
Anyone have a cool list of all text file extensions ?
G
-----Original Message-----
From: info-cv...@gnu.org [mailto:info-cv...@gnu.org]On Behalf Of
Peter Ring
Sent: Sunday, April 01, 2001 11:52 PM
To: CVS-II Discussion Mailing List
Mike Pumford
> Remember that cvswrappers doesn't work if you connect to the repository
> using a remote protocol (e.g. pserver); you must put a copy of the
> 'cvswrappers' file named '.cvswrappers' into each users home directory.
>
Mike
Paul Sander
>The goal of CVS is to to *exactly* what it does and has always done!!!!
>That's it. Nothing more. Nothing less.
If this were really true, then the developers of CVS would have packed
up and gone home long ago. CVS continues to evolve, but not in the
directions that some of us would like to see. CVS didn't always have
a client/server implementation, for example.
The fundamental design of CVS can accomodate many features discussed in
this forum, many of them more readily than a client/server implementation.
>CVS will survive in exactly the places where it fulfills the
>requirements it was designed to fulfill. If those requirements ever
>completely go away, or if any other tool comes along that fulfills those
>requirements in an obviously better way, then maybe CVS will cease to
>"survive", but that'll be a good thing and we'll all rejoice when it
>happens!
>If you put CVS into organisations where it won't do anything but confuse
>them and cause them troubles because it's the wrong tool for their
>requirements then you're doing the WRONG thing! It's no damn wonder
>that sometimes you fail to convince some clients to use CVS! They don't
>all NEED it!!!! You fail in those cases because you have failed to
>understand their requirements and to correctly do the job they hired you
>to do!
CVS, like all software, is very maleable. Like any software tool, it can,
and it should, evolve to suit the needs of its users (and not the other way
around). There are limits to how far CVS can go while retaining its identity
and its niche, but it has a long way to go before it begins to challenge them.
--- End of forwarded message from info...@gnu.org
Greg A. Woods
> Subject: RE: cvswrappers - any better suggestions ?
>
> 20+ years listening to people just like you explain why something
> shouldn't/couldn't be done, and then finding ways to make it happen
> anyway. Clearly, other people feel the same way, because CVS does
> support binary files after a fashion. I just want them supported
> better.
Clearly you do not get it at all. CVS literally cannot support binary
files in any better fashion without becoming something that will no
longer be a "Concurrent Versions System". It was designed specifically
to force concurrent editing and that design goal permeates the way it
works through and through (despite the valiant attempts by others to
bend it to suit their twisted ideas). You cannot throw out the bath
water without throwing out the baby in this case -- they are one in the
same.
Paul Sander
seem to understand the necessity of many proposed features, and who are
influential enough to defer or even actively discourage their introduction.
Examples of such needed features include full support of non-ASCII file types,
directory versioning, more complete and robust refinement triggers, and even a
generalized merge tool registrar. These things have been discussed for years
in this forum, and numerous implementations have been discussed. Nevertheless,
the preference to apply 1988's technology to 2001's programming problems
remains compelling for some.
Unfortunately, there does not seem to be sufficient interest to either
accept such new features into the mainstream, or to splinter off a new
development effort to produce a more capable tool. RCVS was one attempt to
open up and encourage development of new things, but it didn't work out as
was hoped.
So, you have the following choices: Design and build CVS v2.0 from the
ground up and make it a useful tool. Cripple your software development
effort enough that the existing CVS can handle it. Use something else.
Using something else is the fastest and easiest way to get what you want
(and the cheapest in the long run), but crippling your current process may
be the fastest and easiest way to overcome some immediate hurdle and limp
along until the next crisis arises.
--- Forwarded mail from dgl...@home.com
With all due respect, Greg, I think Gianni made some very telling points which CVS will need to address if it is to survive. I'm an independent consultant, and I try to bring CVS into each organization I work with. I'm sometimes successful, but I fail at times for exactly the reasons Gianni articulates.
With the proliferation of MSWord, IDE project files, etc, no reasonable person can argue that non-text files are not a necessary part of most projects these days. If CVS does not 'grow up' and attempt to support the new development environments, it will slowly be replaced by something that does, and CVS will ultimately become a bit player, promoted by a few fanatic users who try to make its case at every opportunity (whether appropriate or not), and ignored or laughed at by the majority of the population.
I've heard your same arguments applied to Forth, OS/2, Geos, Clarion, Lotus 1-2-3, Wordstar, UCSD P-System... the list goes on. I'd hate to add CVS to the list.
--- End of forwarded message from dgl...@home.com
Larry Jones
>
> Nope; CVS adheres to design principles that are at least somewhat
> compatible with our requirements. The fact that people are using
> CVS for the management of binary files implies that somebody can
> do it and be successful. Nor do I understand why this is inherently
> a wrong choice. I can understand why it would be the wrong choice
> under some given circumstances, but I have a great deal of difficulty
> with moral absolutes in open-source software.
People successfully use hammers to insert screws. That doesn't mean a
hammer is the right tool (or even a good tool) for the job.
> Heck, I don't even want to write to tool manufacturers and tell
> them that they need to make screwdrivers more paint-can-lid
> compatible.
But that's exactly what you're doing with CVS.
-Larry Jones
Wheeee. -- Calvin
Paul Sander
at length in this forum many times in the past. His argument is based on
the fact that the RCS "merge" tool cannot support merges of arbitrary
file formats. It doesn't even support merges of arbitrary ASCII formats.
And yet, the CVS community attempts to use it in that capacity all the
time.
There are application-specific merge tools for numerous file formats,
some of which are useful for software development. Others don't exist
but can be written without great effort. When all else fails, there's
always the trivial binary or trinary file selection algorithms. And don't
forget that there are the many existing text-based merge tools that people
prefer using, such as the one supplied with Emacs.
Inserting a registrar into CVS to allow shops and users to specify the
particular tool required to perform a merge is not a fundamental change to
the CVS design, but it is a small generalization. And it's one that will
greatly benefit the CVS community in general. Such a mechanism does NOT
affect in the slightest way ANY aspect of the concurrent development model
that CVS implements. (It is basically just parameterizing the hard-coded
path to the RCS-supplied merge tool, or its equivalent in the librified RCS.)
--- Forwarded mail from wo...@weird.com
>[ On Sunday, April 1, 2001 at 14:00:20 (-0700), David Glick wrote: ]
>> Subject: RE: cvswrappers - any better suggestions ?
>>
>> BTW, I *do* get it; I just don't agree with you. I've spent most of
>> 20+ years listening to people just like you explain why something
>> shouldn't/couldn't be done, and then finding ways to make it happen
>> anyway. Clearly, other people feel the same way, because CVS does
>> support binary files after a fashion. I just want them supported
>> better.
>Clearly you do not get it at all. CVS literally cannot support binary
>files in any better fashion without becoming something that will no
>longer be a "Concurrent Versions System". It was designed specifically
>to force concurrent editing and that design goal permeates the way it
>works through and through (despite the valiant attempts by others to
>bend it to suit their twisted ideas). You cannot throw out the bath
>water without throwing out the baby in this case -- they are one in the
>same.
--- End of forwarded message from wo...@weird.com
David Glick
Your statement "CVS literally cannot support binary files..." should be changed to "CVS does not currently support binary files in a way that is consistent with the philosophy of concurrent editing".
If we can agree with the above statement, then this immediately leads to two possible approaches (or three, if you continue to argue that binary files should not be supported...):
1) Violate the 'concurrent' philosophy with regard to binary files, and implement a locked checkout to allow for straightforward creation of deltas and avoid the messy problems of figuring out how to concurrently update binary files.
2) Allow for concurrent checkout of binary files, but disallow concurrent commits, e.g. only a user that has updated to the current version will be allowed to commit changes.
Neither approach is ideal, but both provide a step in the direction of better support for binary files. I'm sure there are other approaches that may well satisfy other people's needs, too. There may even be a way to fold binary file support completely into the CVS philosophy; I'm just too busy right now to think it through completely (and, unfortunately, I'm *way* to busy to actually do the work... sigh.).
----- Original Message -----
Clearly you do not get it at all. CVS literally cannot support binary
files in any better fashion without becoming something that will no
longer be a "Concurrent Versions System". It was designed specifically
to force concurrent editing and that design goal permeates the way it
works through and through (despite the valiant attempts by others to
bend it to suit their twisted ideas). You cannot throw out the bath
water without throwing out the baby in this case -- they are one in the
same.
Greg A. Woods
> Subject: RE: cvswrappers - any better suggestions ?
>
> up and gone home long ago. CVS continues to evolve, but not in the
> directions that some of us would like to see. CVS didn't always have
> a client/server implementation, for example.
Hmm... I think you're mixing up your history with present day here.
The CVS developers did pack up and go home. Even the ones who picked up
the torch after them have themselves packed up and gone home long ago.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
_______________________________________________
Greg A. Woods
> Subject: RE: cvswrappers - any better suggestions ?
>
> seem to understand the necessity of many proposed features, and who are
> influential enough to defer or even actively discourage their introduction.
Paul haven't you ever wondered why that's so? Perhaps you've got it
backwards. I would suggest that there are enough non-members of the CVS
community who are jealous of the CVS community and would rather twist,
rip, tear, mould, spindle, and otherwise manipulate the CVS community so
that they can join it without changing their own ways.
> Examples of such needed features include full support of non-ASCII file types,
> directory versioning, more complete and robust refinement triggers, and even a
> generalized merge tool registrar. These things have been discussed for years
> in this forum, and numerous implementations have been discussed. Nevertheless,
> the preference to apply 1988's technology to 2001's programming problems
> remains compelling for some.
That's because most true programming is still done with 1970's
technology and so something neat-o-nifty and new like CVS is highly
applicable to most of our daily work and actually makes us more
productive. I doubt there would be any *BSD releases if it were not for
CVS being exactly what it is!
> So, you have the following choices: Design and build CVS v2.0 from the
> ground up and make it a useful tool. Cripple your software development
> effort enough that the existing CVS can handle it. Use something else.
Hear! Hear! Three cheers for Paul! Now could all you people who don't
like the way CVS is designed please follow his helpful suggestions?
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
_______________________________________________
Greg A. Woods
> Subject: RE: cvswrappers - any better suggestions ?
>
> chosen by CVS, much as you get chosen by Microsoft operating systems and
> development tools, simply because it's ubiquitous. Like it or not, there's
> not much respect for original design goals in the ways of the world.
Fortunately CVS is anything but ubiquitous. Even within the open source
world (whatever the heck that is! :-), CVS is not the choice of all the
masses (and of course it's never been the only choice).
> I suppose that 'full RCS compatibility' is not a goal by itself -- if you
> might as well use RCS, then why use CVS?
The issue has more to do with keeping the repository in a standard
format. This is of enormous importance in assuring backward and forward
compatability. A repository is literally something that keeps all of
your eggs in one basket. If you start messing with the weave on that
basket without first removing the eggs then you're as likely to have
them all drop right out the bottom.
One other reason to do this is so that should someone who has a better
idea, and the time to implement and support it, come along then he/she
can be assured that pulling stuff out of any given CVS repository
without having to write custom code to handle what would effectively
become a proprietary (well open, but unique) and possibly changing
format.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
_______________________________________________
Greg A. Woods
> Subject: Re: cvswrappers - any better suggestions ?
>
> Philosophically, this seems to be a Platonist approach to
> software tools, and you're in a community of Aristotelians.
No, you Aristotelians are invading a community where you don't belong.
> What this means is that I believe we don't have archetypes of
> programming tools, in which CVS is judged on its similarity
> to the archetype of program source control systems, but a whole
> lot of existing tools, which are judged on certain criteria
> (philosophically more accidental than essential) such as usefulness.
Hmm.... Indeed that's about the current state of software engineering,
and in particular software configuration management. Unfortunately the
entire industry has a lot to learn about SCM, and even the academic
community just barely have academic ideas about how all of this stuff is
supposed to work.
CVS is, BTW, just one tiny part of the toolset necessary to help
automate SCM, and it's not particularly good as such tools go either.
However it fits the basic mold of Unix software development very well
and as such it has helped the Unix world achieve a higher level of SCM
and to become more productive as a result. Other tools might have been
even more successful at meeting these goals, but either they weren't in
the right place at the right time, or they are not yet invented.
> I apply this sort of philosophy for other tools, also. I don't
> wonder about how screwdrivery a screwdriver is, but rather how
> easily it turns screws and how durable it's likely to be. Given
> a paint can, I don't go to the hardware store and buy a tool
> to open paint cans, I pry off the lid with a screwdriver. It
> isn't designed to open paint cans, is not intended to, and is not
> sold for the purpose. I would assume it's harder to remove a
> lid without bending it with a screwdriver than with a specially
> designed tool (with a screwdriver, you have to pry gently around
> the lid). However, I have screwdrivers and a place to put them.
> I don't want to buy and store a special paint can lid opening
> tool.
Funny, but around here the paint cans come with their own opening tool
(which co-incidentally is a multi-purpose tool that also opens the beer
bottles you'll be handing around to all the friends you've invited over
to help you paint! :-) Most stores hand out two for every can! :-)
Indeed the reason there are people prying versions of binary files out
of their CVS repositories is because people generally do just choose to
use the first thing that drops into the palms of their hands instead of
taking the time to find the right tool for the job. Unfortunately in
the more virtual world of software engineering people are incredibly bad
at making even roughly correct estimates in how much time they might
save, or how much more productive they might be, by choosing the first
tool that appears in front of them instead of doing a proper analysis
and searching for the right tool.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
_______________________________________________
Greg A. Woods
displayed on the average terminal? Thanks! ]]
[ On Monday, April 2, 2001 at 12:20:34 (-0700), David Glick wrote: ]
> Subject: RE: cvswrappers - any better suggestions ?
>
> Your statement "CVS literally cannot support binary files..." should
> be changed to "CVS does not currently support binary files in a way
> that is consistent with the philosophy of concurrent editing".
>
> If we can agree with the above statement, then this immediately leads
> to two possible approaches (or three, if you continue to argue that
> binary files should not be supported...):
No, unfortunately we cannot agree on that statement. It is wrong (in
fact it's completely self-contradictory!), and it points out why you're
"not getting it" (at least to me).
BTW, binary opaque files should probably never be supported by any
source code control system that supports any form of merging. ;-)
Note though that I have never argued against the concept of inventing
merge tools that can properly merge non-text files. In fact I've longed
for tools that can merge source at a syntax level instead of a lines of
text level! (Emacs ediff gets close in that it can combine its
capabilities with syntax highlighting and make at least manual merges
much easier. Rumour has it that BitKeeper has a very good merge tool
too.)
However until someone can specify a repository format that can take a
CVS-like tool beyond RCS, this is all just blue-sky dreaming.
I.e. CVS literally cannot support *binary* files!
> 1) Violate the 'concurrent' philosophy with regard to binary files,
> 1) and implement a locked checkout to allow for straightforward
> 1) creation of deltas and avoid the messy problems of figuring out how
> 1) to concurrently update binary files.
That's what plain RCS, plain SCCS, and other basic tools built atop of
them do today. There's a multitude of such tools, both freely available
and proprietary. If this is your approach then drop CVS and choose one
of those tools.
You cannot make CVS do #1 without changing it into something that cannot
be a "CVS". (Indeed the watch/edit facilities can help developers who
fail to work in the "concurrent editing" mode communicate, especially
when they haven't already got other good ways of communicating amongst
themselves. These features are not a substitue for #1 though and they
only help a tiny bit with the binary file issues.)
> 2) Allow for concurrent checkout of binary files, but disallow
> 2) concurrent commits, e.g. only a user that has updated to the
> 2) current version will be allowed to commit changes.
That's exactly what CVS does now. The problem is with the "update"
part. CVS currently forces the burden of choosing between one version
and another on the "loser" of the checkin race.
However that's not the only problem -- there's also the problem of
merging changes between branches. The more binary files you have the
less you can succeed with such merges.
Even if someone invents automated merging tools that could replace diff3
(i.e. rcsmerge) you cannot use them in CVS without changing the
repository format at a very fundamental level.
It's interesting to note that PRCS can do merges of text files with a
binary delta storage format (xdelta) just as well, if not better, than
diff3 can do.
> Neither approach is ideal, but both provide a step in the direction of
> better support for binary files.
If you don't like the tradeoffs of #2 then don't use CVS. Period.
> I'm sure there are other approaches
> that may well satisfy other people's needs, too.
There is a "two phase" commit approach, and there are tools available
which implement it (one of the free ones being Aegis). This approach
has many advantages over CVS in some types of environments. Note that
for binary files it still really only just shuffles the blame around in
a different way and shoulders the responsibilities for choosing change
sets on different roles in the process.
> There may even be a
> way to fold binary file support completely into the CVS philosophy;
You really should read the relevant threads in the past four or five
years of this forum before you promote such a mistaken idea! ;-)
> I'm just too busy right now to think it through completely (and,
> unfortunately, I'm *way* to busy to actually do the work... sigh.).
I can appreciate that. However it's no excuse though for blaming CVS
for being designed the way it is. It's not even really a valid excuse
for using CVS when some better tool would make your work more
productive.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
_______________________________________________
Greg A. Woods
> Subject: RE: cvswrappers - any better suggestions ?
>
> at length in this forum many times in the past. His argument is based on
> the fact that the RCS "merge" tool cannot support merges of arbitrary
> file formats.
Well, sort of. It's a little deeper than that, of course.
> It doesn't even support merges of arbitrary ASCII formats.
Well, no, but that's partly the point! ;-)
> And yet, the CVS community attempts to use it in that capacity all the
> time.
And with remarkable success, success that's been scientifically
documented ever since CVS-II was released.
Indeed there are several other tools with the same basic design for
support of concurrent editing and they are equally successful.
Of course programmers who have used CVS for a long time will inherently
learn little tricks that make actual merge conflicts even less likely to
occur except where absoutely necessary. Indeed there are even
programming tricks that can make accidental hidden conflicts less
likely.
And of course the CVS source itself provides a half-decent example of
the benefits of automated product testing.
> Inserting a registrar into CVS to allow shops and users to specify the
> particular tool required to perform a merge is not a fundamental change to
> the CVS design, but it is a small generalization.
Yes, but one that would require a rather drastic revision to the
repository format.
> And it's one that will
> greatly benefit the CVS community in general.
I'm not so sure. If it were so it would have been done long ago and
offered back to the community. As it is we don't even have a sample
implementation to show to the community and to prove that such a forward
change in the repository format would succeed.
> Such a mechanism does NOT
> affect in the slightest way ANY aspect of the concurrent development model
> that CVS implements. (It is basically just parameterizing the hard-coded
> path to the RCS-supplied merge tool, or its equivalent in the librified RCS.)
I agree whole-heartedly.
I'm just not restricting my view to one set of concerns....
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
Paul Sander
>> Inserting a registrar into CVS to allow shops and users to specify the
>> particular tool required to perform a merge is not a fundamental change to
>> the CVS design, but it is a small generalization.
>Yes, but one that would require a rather drastic revision to the
>repository format.
>> And it's one that will
>> greatly benefit the CVS community in general.
>I'm not so sure. If it were so it would have been done long ago and
>offered back to the community. As it is we don't even have a sample
>implementation to show to the community and to prove that such a forward
>change in the repository format would succeed.
co -p <common-ancestor-revision> file > .file.base
co -p <other-contributor> file > .file.contrib
my-merge-tool --base .file.base --contributor .file.contrib file
This algorithm can be easily implemented with CVS (in fact, I believe it
already is). And it does not require any change to the repository format,
other than providing a means to specify what my-merge-tool really is.
--- End of forwarded message from info...@gnu.org
David Glick
> [[ Could you please learn to format your text so that it can be properly
> displayed on the average terminal? Thanks! ]]
Since I'm using an Open Source mail agent (which I'm trying to find time to contribute to), I'll take this as an enhancement request and add it to the list... <g>
>>
>> Your statement "CVS literally cannot support binary files..." should
>> be changed to "CVS does not currently support binary files in a way
>> that is consistent with the philosophy of concurrent editing".
>>
>> If we can agree with the above statement, then this immediately leads
>> to two possible approaches (or three, if you continue to argue that
>> binary files should not be supported...):
>
> No, unfortunately we cannot agree on that statement. It is wrong (in
> fact it's completely self-contradictory!), and it points out why you're
> "not getting it" (at least to me).
Well, you're right this time; I don't get it. How is my statement contradictory?
>> 1) Violate the 'concurrent' philosophy with regard to binary files,
>> 1) and implement a locked checkout to allow for straightforward
>> 1) creation of deltas and avoid the messy problems of figuring out how
>> 1) to concurrently update binary files.
>
> That's what plain RCS, plain SCCS, and other basic tools built atop of
> them do today. There's a multitude of such tools, both freely available
> and proprietary. If this is your approach then drop CVS and choose one
> of those tools.
>
> You cannot make CVS do #1 without changing it into something that cannot
> be a "CVS". (Indeed the watch/edit facilities can help developers who
> fail to work in the "concurrent editing" mode communicate, especially
> when they haven't already got other good ways of communicating amongst
> themselves. These features are not a substitue for #1 though and they
> only help a tiny bit with the binary file issues.)
Greg, what you're arguing here is that it is impossible for #1 to be implemented without changing the repository. I agree. However, it is certainly feasible that this change would be fully backward compatible with the repository as it exists today. Of course, it's also true that the repository would *not* be 'forward compatible', e.g. you could not use an old CVS server on a new repository with regard to binary files.
However, I disagree with the notion that I should drop CVS for something that supports binary files better. I *like* the way CVS supports source code editing; I think it makes development groups *more* productive. But binary files are almost always an annoying problem in most modern development environments that I have to find a way to deal with. The current support CVS has for binary files is ok, but not great. Better binary support, even if it fails to fully support the 'concurrent' philosophy, would at least allow me to leverage the benefits of CVS for what it does best.
>> 2) Allow for concurrent checkout of binary files, but disallow
>> 2) concurrent commits, e.g. only a user that has updated to the
>> 2) current version will be allowed to commit changes.
>
> That's exactly what CVS does now. The problem is with the "update"
> part. CVS currently forces the burden of choosing between one version
> and another on the "loser" of the checkin race.
Perhaps you can educate me here. I was under the impression that CVS did not supports deltas when dealing with binary files, but rather copied the modified binary file completely. Is this not accurate?
>> Neither approach is ideal, but both provide a step in the direction of
>> better support for binary files.
>
> If you don't like the tradeoffs of #2 then don't use CVS. Period.
Or else modify CVS to better meet my needs, assuming that it also meets the needs of other users and doesn't impact its use by 'old timers'. Now, if nobody but myself would find these modifications useful, I fully agree I should go find something else to use. However, in the short amount of time I've been monitoring this list, this issue seems to come up a lot. You can argue that it's because those people are newbies and don't 'get it'. I'd argue that it's because CVS is flawed in this instance.
>> There may even be a
>> way to fold binary file support completely into the CVS philosophy;
>
> You really should read the relevant threads in the past four or five
> years of this forum before you promote such a mistaken idea! ;-)
<g> I'll add it to my reading list. However, you're doing a great job in summarizing the arguments. I'm just curious if I'm rehashing old argurments or coming up with anything new.
>> I'm just too busy right now to think it through completely (and,
>> unfortunately, I'm *way* to busy to actually do the work... sigh.).
>
> I can appreciate that. However it's no excuse though for blaming CVS
> for being designed the way it is. It's not even really a valid excuse
> for using CVS when some better tool would make your work more
> productive.
I'm not blaming CVS; as I said, I *like* CVS, and I fully buy into its general development model. I do believe that the 'Concurrent' in CVS is what makes it superior to most other tools. Having said that, I'd like a better way to handle binary files, even if its not 'concurrent' in this instance (and I accept that this *is* contradictory <g>).
David Glick
Transmit Consulting, Inc
619-475-4052
dgl...@home.com
David H. Thornley
"Greg A. Woods" wrote:
>
> [ On Monday, April 2, 2001 at 09:56:28 (-0500), David H. Thornley wrote: ]
> > Subject: Re: cvswrappers - any better suggestions ?
> >
> > Philosophically, this seems to be a Platonist approach to
> > software tools, and you're in a community of Aristotelians.
>
> No, you Aristotelians are invading a community where you don't belong.
>
Y'know, it can be really difficult to figure out whether you're
surrounded by Platonists or Aristotelians.
>
> Funny, but around here the paint cans come with their own opening tool
They do? I've always used the screwdrivers. (Am I buying my
paint in the right places?)
> Indeed the reason there are people prying versions of binary files out
> of their CVS repositories is because people generally do just choose to
> use the first thing that drops into the palms of their hands instead of
> taking the time to find the right tool for the job. Unfortunately in
> the more virtual world of software engineering people are incredibly bad
> at making even roughly correct estimates in how much time they might
> save, or how much more productive they might be, by choosing the first
> tool that appears in front of them instead of doing a proper analysis
> and searching for the right tool.
>
Here's the situation I'm looking at.
We do most of our work in conventional programming languages like
C++ and Java and Perl, and these work very well with CVS. We use
HTML for some documentation, and that generally works well
(although I have little experience with CVS storing the abominations
you get when saving as HTML from Word). We have things like
release branches and patch branches. What this means is that
CVS works very well for most of the stuff we do.
On the other hand, there is stuff mixed in there that is not
source code. One example would be image files for the HTML.
These files are most conveniently located in the same directory
as the HTML files, and in some cases source files.
This means that we have three choices.
1. Continue to use CVS, accepting the problems with binary files.
2. Use a combination of CVS and some other system that handles
binary files better.
3. Switch to another tool entirely.
Realistically, (2) isn't going to fly. CVS and the other system would
have to be too closely intertwined, and nobody wants to learn another
SCM system. This leaves (1) and (3).
The problem with (3) is that CVS is very good for most of what we
do. We need things like branches and concurrent development, and
the fact that it has been working for a long time with few
problems. Our source code is the company's most valuable asset
(not counting people). Reliability and confidence are good things
for this. If we were to go to another system, we would not have
the same trusting feeling, and would go through a learning curve.
I'm not saying we're going to use CVS forever, but any replacement
needs to have much the same features as CVS or productivity is going
to take a real hit.
So, if somebody can point to a SCM system that has the same reliable
reputation, doesn't cost too much, and does the same sorts of things,
I'm listening. Otherwise, in a world where none of the tools
exactly match my needs, I'm going with what seems to me the best
choice, and right now that's CVS.
--
David H. Thornley Software Engineer
at CES International, Inc.: David.T...@ces.com or (763)-694-2556
at home: (612)-623-0552 or da...@thornley.net or
http://www.visi.com/~thornley/david/
_______________________________________________
Alexander Kamilewicz
>
> Here's the situation I'm looking at.
>
> We do most of our work in conventional programming languages like
> C++ and Java and Perl, and these work very well with CVS. We use
> HTML for some documentation, and that generally works well
> (although I have little experience with CVS storing the abominations
> you get when saving as HTML from Word). We have things like
> release branches and patch branches. What this means is that
> CVS works very well for most of the stuff we do.
>
> On the other hand, there is stuff mixed in there that is not
> source code. One example would be image files for the HTML.
> These files are most conveniently located in the same directory
> as the HTML files, and in some cases source files.
This is very similar to my environment, although as well as images we
have lots of .mov, .fla, .swf, .doc, .xls, & assorted binary files.
> This means that we have three choices.
>
> 1. Continue to use CVS, accepting the problems with binary files.
> 2. Use a combination of CVS and some other system that handles
> binary files better.
> 3. Switch to another tool entirely.
We do #1. The only problem with #1 is that you're going to have a
repository that grows rather rapidly. We realized that and invested in
a Network Appliance. My repository is now 33Gb large.
However, since the bulk of our problems with binary files is: "Here's a
new version of that image/movie/flash/whatever, have fun" we decided
that it would be pointless, at this point, to move to another SCM tool
when CVS fits so well into the toolkit of the developers doing the .htm,
.jsp, and .js files.
I think it's worth noting that one of the pre-eminent SCM tools for
version control/management of images/flash/movies, called MediaWay,
doesn't store "diffs" but stores a copy of every version of every
element ever entered into and/or modified in its repository.
That's basically what CVS does. So CVS isn't particularly far away from
that functionality.
If you have a need for a tool that provides more and better information
on complex binary files (images/flashes/movies), then you can do what we
do. Buy MediaWay, have the graphics dudes use it, and use cvs import
when they have new versions.
It works OK for us.
Alex