[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion 0.7 released.

From: <cmpilato_at_collab.net>
Date: 2001-12-04 16:13:49 CET

Billy Tanksley <btanksley@hifn.com> writes:

> I just spent a year fighting CVS, because Tornado/NT for vxWorks uses Unix
> line endings on its project files, and insists on them. I didn't know that,
> and more importantly, neither did the person who made the projects and
> checked them into CVS. (That person made a real hash out of everything, so
> recreating all the files is a MAJOR pain in the rear, one I'm facing for the
> first time now.)
>
> I'd rather not have the decision be heuristic -- just version control my
> files, and if I want keyword expansion, I'll be sure to tell you. I'm glad
> to have the heuristic, of course; it's better than nothing, and I'm sure
> it'll help in some situations. It wouldn't have helped in mine, I'm sure;
> unless the heuristic was to assume no CRLF expansion unless (1) the file
> looks textlike and (2) users on appropriate platforms keep checking in the
> file with line endings changed to fit their platforms.

Current heuristic is:

  /* Right now, this function is going to be really stupid. It's
     going to examine the first block of data, and make sure that 85%
     of the bytes are such that their value is in the ranges 0x07-0x0D
     or 0x20-0x7F, and that 100% of those bytes is not 0x00.

     If those criteria are not met, we're calling it binary. */

> >Honestly, I have the same preference. In fact, my preferences
> >regarding what I wish Subversion would do (or more specifically, not
> >do) extend beyond that, and can be basically summed up by: Subversion
> >should version file contents and user properties. That means no
> >versioning of file permissions, no newline conversion, no keyword
> >substitution.
>
> I'd love that.
>
> >Alas, I have a feeling I'd be strongly outvoted on many (all?) of
> >these points, though, and ultimately, I want Subversion to rock CVS'
> >world. So I code on...
>
> Yes, svn has to plug in where CVS is now. I'd sure like it if that meant we
> didn't repeat CVS' mistakes. I can understand, though, that some people
> need that feature -- in particular, keyword substitution is a handy thing to
> have in a version control utility. (I don't see line ending substitution as
> being useful; I don't know how that got in here. I can see line ending
> agnosticism being useful, though, to keep from recording false diffs -- but
> by the same argument I can see arguing running all C source code through an
> automated reformatting at every checkin, and nobody suggests making that
> part of a version controller.)

(included all the above to the rest of the list can read it. not that
i don't like personal email and all, but such discussions --
especially when they include stories of a user's past experiences with
versioning systems -- are of interest to all)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:51 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.