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

Re: [Billy Tanksley <btanksley@hifn.com>] RE: Greg Hudson's EOL system.

From: William Uther <will=subversion_at_cs.cmu.edu>
Date: 2001-12-12 20:37:25 CET

--On Wednesday, 12 December 2001 12:25 PM -0600 Ben Collins-Sussman
<sussman@collab.net> wrote:

> From: Ben Collins-Sussman [mailto:sussman@collab.net]
>> And most importantly, the corruption never *really* happens, at least
>> not in Greg's system. The original version in the repository is
>> always uncorrupted, as is any text-base copy that somebody gets. Any
>> 'corruption' is purely a superficial thing that only happens in the
>> working area. A user can easily revert the working file and make sure
>> no translation happens (though any number of methods.)
>
> I do like this property. It may be that this is the only possible
> compromise between the two camps.
>
> It's just odd that this transform should be built into the software, while
> other equally valid ones are bolt-ons. For example, people were talking
> about C++ code being automatically deformatted (perhaps one word on each
> line) on checkin and then reformatted on checkout. Not everyone will want
> this -- but for the ones who DO want it, the argument is almost exactly
> the same as the argument for line ending conversion.
>
> Perhaps that's the answer -- make line ending handling into an 'external'
> feature (i.e. one which uses the extension API), which just happens to be
> shipped with Subversion. It can be an example of how to use that API, so
> if someone wants to build that C++ reformatter, they can use the line
> ending formatter as a starting point.
>
> Best of all worlds -- and if someone really gets irritated with it, or
> doesn't need it at all, they can just unplug it, because it's nothing but
> a pre and post-processor.

I like this concept. It's like the concept of pluggable diff engines:
pluggable conversion scripts. It also means that you could handle other
conversions nicely - e.g. UTF-8 -> OldRussianEncoding
You could also do the keyword conversion using the same framework. If
someone wants their keyword conversion using wacky new strings, they just
have to edit the keyword conversion script.

+ (lurker coefficient) * 1

One thing I'm not sure about... Why is the conversion happening between the
base copy and the working copy? Why not between the repository and the
base copy?

I can see that it is 'kinda nice' for the base copy to always equal the
repository copy, but is that work the fact that you're ending up with three
local copies: i) base copy, ii) converted base copy and iii) working copy.
(ii is only around temporarily, but if you have it, why do you need i?).

later,

\x/ill :-}

---------------------------------------------------------------------
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:52 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.