Re: How well does CVS handle other types of data?

[Greg A. address@hidden (Greg A. Woods)]

[ On Saturday, July 14, 2001 at 01:28:12 (-0700), Paul Sander wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> And just how is this done?  Do you use artifacts of the programming language
> to somehow format the marker into something that is not detectable by CVS?
> What if the language provides no way to do this?  Seems to me that in that
> case you're screwed either way.  You can't put them in because your tool
> breaks.  You can't leave them out because CVS disallows commits if you do.

Why don't you look at doc/cvs.texinfo and src/sanity.sh and figure this
out for yourself?

> What does that have to do with anything?  The tools don't read the comments.

Who said anything about comments?  I certainly didn't.  I said
"document".  There's a difference.

> Any programmer experienced in that hypothetical language can differentiate
> between CVS' conflict mark-ups and correct syntax.  An experienced
> programmer on the project knows whether or not the construct in question
> is valid.  Escapes buy nothing.

You're not paying attention to the issues.

> In any case, it's not CVS' place to impose any kind of standard on the content
> of the files it manages.

Well, obviously you live in a dream world where everything's got to be
perfect or else it's useless.

CVS imposes many subtle issues on the content of the files it manages,
and I'm not talking just about them being "RCS mergable".

> Yes, it is rare.  But the user is in for a big surprise if CVS disallows
> a commit because it doesn't like the contents of a file.  The fact that
> it is unlikely to happen does not give CVS license to impose a coding
> standard.

I beg you to please go away and use your commercial software, where your
purchase dollars can influence your vendor to create a "perfect" product
for your needs.

> It is precisely because I HAVE performed and supported difficult merges,
> including with binary sources (which you admitedly avoid), that I crave much
> better support for it.  CVS has lots of room to improve, and this is one such
> area.

Well, I've just done something about it in the version of CVS I use.  It
works GREAT!

> I looked at the CVS sources just now.  Hasn't changed much lately.  There
> are two functions that perform the guts of the merge.  The first is the
> RCS_merge function, which performs the ASCII-based merge we all know and
> love.  One level up is the merge_file function, which puts a better face
> on it, and implements the -kb support.  The interfaces of both are quite
> clean, and the call graph is such that there is little chance that changing
> either of them will break something else.  It appear offhand to be trivial
> to insert new merge capabilities; well, nothing is trivial in programming,
> but this certainly does not involve "drastic changes" that Greg promises.

How little you understand what's really going on in there it seems......

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>