On Monday, February 14, "Win32 M$" wrote:
>
> >Welcome to branches, and tags. Please read the manual. Please read the
> >manual.
> >No, please read the manual. Print it out, and read it again. Also, if you
> >wish,
> >there are ways of stoping a commit (using commitinfo). Again, read the
> >manual.
>
> You are reading the manual in some strange way - you do not see that the
> locking is already there - in it's worst form...? Read the manual - but all
> of it, do not skip the parts...
You know I've read that part of the manual. I've sent a comprehensive outline
of the locking issue to this list before. You said that you needed locking for
release management. I told you that CVS does not do it this way, it advocates
using branches and tags.
> Again, please stop to tag the text files binary, OK? VB form files are text,
> and not binary, got it?
Just because they look text, does not mean they are text. Cripes, mathematica
notebooks are "text" too, but they have an "index" of sorts in the header, and
mathematica will complain if the index does not match up with the rest of the
"text" file. A merge knows *nothing* about the format of a file, except that
it is text. If you don't want to have merge conflicts, or merge corruptions,
then tag the bloody thing binary. There is more structure there than simple
line by line text.
> OK, short intro. VB will keep the code in two files, which are related to
> each other. One is the form file - "*.frm", the other with the same
> filename, but ".frx" extension is a binary file which corresponds to the
> ".frm" file. Now, the ".frm" file has mainly two parts - one is on top of
> it, and is kind of the header, which defines all the controls and it's
> properties. The other is the 'real' code. Normally, in the VB IDE you will
> only see the code part - the header is analized by the IDE, and then you can
> change the properies in the Visual editor. The header part will always be
> recreated - and it looks like the large blocks of code are moved up and
> down, affecting many lines. The code part is more stable. Now, to properly
> handle that system, you need to:
> 1. Keep the file consistant.
> 2. Keep the related 'frm' and 'frx' files in consistancy.
Again, I understand, welcome to "binary" files.
> >As you wish, the manual does say "use at your own peril" (paraphrased), so
> >you
> >are free to do so of course.
>
> This apply to the CVS as a whole. Read the manual and THINK! No software
> gives any warranty. Read the warranty, read the warranty....
Sure, no warranty for CVS, but 'cvs admin' is documented as "possibly changing
in the future, incompatibly, maybe going away". Again, if you with to use
that feature, you are free to do so.
--Toby.
