[Billy Tanksley ] RE: Greg Hudson's EOL system.

[Ben Collins-Sussman <su...@collab.net>]

From: Ben Collins-Sussman [mailto:sussman@collab.net]
>Billy Tanksley <bt...@hifn.com> writes:
>> This would result in svn acting like CVS -- it'd appear to 
>> corrupt binary
>> files.  (Of course, the binary file can simply be changed to 
>> actually be binary, in which case everything's fine.)

>Well, again, this is user error.  If a file is binary, make sure svn
>thinks so.  It already has a heuristic for guessing... and you can
>always directly tell it so.

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

-Billy

Re: Greg Hudson's EOL system.

[Ben Collins-Sussman <su...@collab.net>]

Justus Pendleton <su...@ryoohki.net> writes:

> As someone who once suggested that there be a way to format/deformat
> source code on checkin/checkout and was told that the repository
> shouldn't ever munge the data, count me in as someone who finds it
> strange that line endings are for some reason exempted.

But that's the point of greg's system:  the repository still doesn't
munge any data coming in or out, *and* we make a guarantee that the
client won't munge any data you send to the repository.  At most, the
client has the ability to give the user a comfortable illusion of the
working files.  The important point here is that the illusions only
exist in the client;  the repository never creates any.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Greg Hudson's EOL system.

[Justus Pendleton <su...@ryoohki.net>]

Billy Tanksley <bt...@hifn.com> writes:
> 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.

As someone who once suggested that there be a way to format/deformat
source code on checkin/checkout and was told that the repository
shouldn't ever munge the data, count me in as someone who finds it
strange that line endings are for some reason exempted.  As I
suggested once before, I think that making line ending conversion and
keyword expansion "external" features makes the most sense to me.  It
also solves the problem mentioned earlier about people asking for
$NetBSD$ and $Id$ keywords.  If they're not hard coded parts of the
application but rather an easily modified extension, people can
implement what they want without obscure hacks or having to fork the
source.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Billy Tanksley ] RE: Greg Hudson's EOL system.

[William Uther <wi...@cs.cmu.edu>]

--On Wednesday, 12 December 2001 2:37 PM -0500 William Uther 
<wi...@cs.cmu.edu> wrote:

> 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?).

Ugh - this is needed for the binary diffs, right...  I'll crawl back into 
my hole now....

\x/ill         :-}


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Billy Tanksley ] RE: Greg Hudson's EOL system.

[William Uther <wi...@cs.cmu.edu>]

--On Wednesday, 12 December 2001 12:25 PM -0600 Ben Collins-Sussman 
<su...@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