info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Info-cvs Digest, Vol 3, Issue 42


From: Matthew Herrmann
Subject: RE: Info-cvs Digest, Vol 3, Issue 42
Date: Wed, 26 Feb 2003 10:52:33 +1100

Hi Doug,

> Yes, that is what I am saying.  We have a multi-platform build
> environment here. There are basic three phases:

Okay, I assume this is for creating builds, and not part of your day-to-day
work. Ie. build ~= release /= coding

> Then what is the point of the cvswrappers MERGE directive?  Clearly,
> if diff can be told to try to diff two binary files, then CVS
> should be able to diff two files marked -kb if the MERGE directive
> so stipulates.

No idea re the MERGE directive. But what you want exceeds the diff features
available in CVS. GNU Diff can be told to diff binary files, but all you
will get is "files are different" or "files are the same". Diff3 has no
capacity for binary diffs, so it cannot make sense of the files. Your only
bet would be to 'trick' diff3 into momentarily forgetting that you have told
it they were binary files. But this is going down a deep rabbit hole.

Given that your build/release process is a one-way process (and so it's more
an export from CVS instead of a checkout), i really do believe your best
option is then to include a unix2dos command just before you build the vb
source.

> And sure, I could also checkout on Windows-- but that too is like
> the tail wagging the dog from a multi-platform build env.
Do you cvs commit, cvs diff, etc. all from your Unix machine, or from a
windows box when you work on the vb code? I assume you have a separate copy
of cvs running there for the day-to-day development and you don't copy your
code back to a unix pc to commit it.

In this case, you may as well do your everyday work in an environment that
VB is comfortable with.

So, further understanding the problem I would suggest:
1. Change all vb frm, cls, mdl, source files to -kkv (text mode)
2. Use CVS on your windows box to check out code in CRLF mode while you
develop
3. Add a step to your release process just before it compiles the VB code to
change the line ending to CRLF.

I don't think you can dispute that this will make your day-to-day
development easier, and will not impact on your build process, plus CVS is
being used more in the manner "they" intended. (which has no merit except
that things tend to work better when it is).

> The fix should, IMHO, be applied to the server. Maybe this feature
> (cvswrappers MERGE directive) is what CVS developers had intended
> to do, but have not yet fully implemented. I wish some of them
> would kindly speak up. :-)

I doubt it. From my reading of this newsgroup, I think you would get the
response that:
 - text modes (LF vs CRLF) should not be crossed between platforms, and cvs
should not be forced to do it (so WinCVS gets a big cross)
 - -kb should only be used for truly binary files, and then sparingly (Greg
Woods in particular, and many others grudgingly)

HTH,

Matt

-----Original Message-----
From: Douglas Finkle [mailto:address@hidden
Sent: Wednesday, 26 February 2003 04:37
To: 'Matthew Herrmann'; info-cvs (E-mail)
Subject: RE: Info-cvs Digest, Vol 3, Issue 42


Matt, thanks for your response.

> are you saying that they must be checked out to unix format,
> even on windows machines? then how does Visual Basic compile
> the source code, since it expects it in CRLF format?

Yes, that is what I am saying.  We have a multi-platform build
environment here. There are basic three phases:
        1. code check out on a master platform (is UNIX)
        2. do platform independent stuff
        3. build platform-specific code (Solaris, HPUX, Windows, etc.)

>From a process perspective it makes sense to have the code checkout
occur on one machine, from a single repository.

But in order for VB, etc. stuff to build the sources need to be
-kb'ed.... which is much less than optimal for ASCII (mergable) files.

> -kb is used to tell cvs not to presume to know what an
> end-of-line character should look like. you cannot have this
> and also do (line-based) merges, since it doesn't know what the
> end of a line is!

Then what is the point of the cvswrappers MERGE directive?  Clearly,
if diff can be told to try to diff two binary files, then CVS
should be able to diff two files marked -kb if the MERGE directive
so stipulates.

I can, if necessary, create make rules that use the Cygwin toolset
to apply unix2dos, and then again do something similar in a
commitinfo hook.  Possible, but messy.

And sure, I could also checkout on Windows-- but that too is like
the tail wagging the dog from a multi-platform build env.

The fix should, IMHO, be applied to the server. Maybe this feature
(cvswrappers MERGE directive) is what CVS developers had intended
to do, but have not yet fully implemented. I wish some of them
would kindly speak up. :-)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]