[Top][All Lists]

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

Re: [Axiom-developer] viewport in build-improvements

From: Waldek Hebisch
Subject: Re: [Axiom-developer] viewport in build-improvements
Date: Fri, 3 Nov 2006 22:07:29 +0100 (CET)

root wrote:
> > > Sure many files *look* like text files, but you have heard Tim saying that
> > > 
> > > 1) a SCM should never change the line ending format
> > 
> > Tell that to Windows folks.
> Consider the domain and range of an SCM. It should map files to files
> as an identity operation with a side-effect of maintaining history.
> An SCM only needs to know that bytes are bytes. Maintaining history
> as diff-format files is an optimization, not a requirement.

I think you miss the point here: you treat SCM like a backup device.
With such an attitude CVS should work fine for you... For me an
essential feature of SCM is ability to concisly and adeqatly summarize
differnces (managing changesets). Also, SCM is really a convenience
device for developers (note that in principle one can just just
a bunch of shell scripts as an SCM). In particular, checkout
should give "ready to build" sources. Now, in many cases
files containing '\r' will not work on Unix, OTOH without '\r'
the same files will not work on Windows.

> Changing \n-files to \r\n-files is the responsibility of some other tool.
> If the translation occurs at all it should live in the client end since
> that is the part that knows about the user environment.

In general, I do not like automatic convertions of line endings. But
IMHO SCM are an exception: usually there is clear separation
between binaries and text files, and since SCM stores metadata,
it can also store information about text/binary properties.
External tool would be forced to guess (and likely to be wrong).
I agree that that conversion should be done in client part of SCM.

> Although I chose arch and it "does the right thing" I have to say
> that GIT seems to have the SCM philosophy most clearly implemented.

I looked quickly at GIT, and I do not think it will be succeful
as-is.  It may "mature" and get extra functions present in other
SCM-s or alternatively some other "higher level SCM" may use
GIT as a backend. ATM the main strong point of GIT is its
packing algoritm, but alone that is too little to win.

                              Waldek Hebisch

reply via email to

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