Re: Migrating repository from Windows to UNIX and eol-style

[Erik Huelsmann <eh...@gmail.com>]

Joe, Ryan,

Sorry to clip all the content from the message, but I just have to say:

* the problems you indicate with svn:eol-style are certainly not
Subversion problems:
  - cygwin considers LF its line ending, that's just its way to make
it look like another POSIX system...
  - moving working copies between systems which have different
line-endings is a problem with or without svn:eol-style: it's a
problem with the environment you work in. If you move your work
through a commit/update cycle, everything works fine. Everything else:
you're on your own (just as you were without Subversion).

* Subversion was intentionally designed not to modify files under
version control until explicitly told to do so. You may not think your
files changed when you want different line-endings, but others may:
say you checked in a subversion dump file. If the system started to
subsitute line endings for you, the file would have been damaged
beyond repair, even though it looked texty. The default is (and
*should stay*) to protect your data.

Please don't project any problems you may have right this instant on
the version control system you're using: your problems are (largely)
unrelated to version control, but to inter-OS moving of files.

bye,

Erik.

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

Re: Migrating repository from Windows to UNIX and eol-style

[Ryan Schmidt <su...@ryandesign.com>]

On Jul 3, 2006, at 18:05, Joe wrote:

> Erik Huelsmann wrote:
>> Right. We learned from CVS in this respect: many a time people forgot
>> to use the 'this is a binary file, please don't modify'-option when
>> adding an image to the repository. Most of them were damaged,
>> sometimes not even recoverable (because the original was deleted).
>
> OK, that's the strongest argument for doing it the Subversion way  
> (and I won't press the issue further).
>
>> Absolutely. This is one of Subversion's weak spots. You as a sysadmin
>> can prevent the file ending up in the repository by checking for the
>> right properties and rejecting the 'newbie commit' in a post-commit
>> hook.
>> [snip] If you have resources to spare (time to discuss design or
>> implementation), you're most welcome to come to dev@ and stirr up the
>> discussion again. You can read about it all through the mailing list
>> archives at http://svn.haxx.se/dev/
>
> I don't have much time to spare, but I'm thinking that one thing  
> that would help sysadmins is some way of storing default properties  
> at the server, e.g., allowing a project to specify something like  
> "from this tree node down, all .c/.h files are defaulted to text  
> and svn:eol-style native, and all .jpg/.png files default to the  
> respective image mime-types".  Of course, one can implement this by  
> storing a config file (or config template) at that point in the SVN  
> tree (or some parallel tree) and require developers to fetch it and  
> adapt it as their first order of business, but a Subversion- 
> provided facility would be preferable.  What is the rationale for  
> not storing default props at the server?

I'm not sure what the rationale is, other than maybe it hasn't been  
high enough on anyone's priority list to work out exactly how such a  
feature should be implemented. But it's certainly possible to write a  
pre-commit hook that implements that behavior. If I ever get around  
to writing my web-based Subversion administration toolkit, that would  
be one of the scripts I'd provide.



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

Re: Migrating repository from Windows to UNIX and eol-style

[Joe <de...@freedomcircle.net>]

Erik Huelsmann wrote:
> Right. We learned from CVS in this respect: many a time people forgot
> to use the 'this is a binary file, please don't modify'-option when
> adding an image to the repository. Most of them were damaged,
> sometimes not even recoverable (because the original was deleted).

OK, that's the strongest argument for doing it the Subversion way (and I 
won't press the issue further).

> Absolutely. This is one of Subversion's weak spots. You as a sysadmin
> can prevent the file ending up in the repository by checking for the
> right properties and rejecting the 'newbie commit' in a post-commit
> hook.
> [snip] 
> If you have resources to spare (time to discuss design or
> implementation), you're most welcome to come to dev@ and stirr up the
> discussion again. You can read about it all through the mailing list
> archives at http://svn.haxx.se/dev/

I don't have much time to spare, but I'm thinking that one thing that 
would help sysadmins is some way of storing default properties at the 
server, e.g., allowing a project to specify something like "from this 
tree node down, all .c/.h files are defaulted to text and svn:eol-style 
native, and all .jpg/.png files default to the respective image 
mime-types".  Of course, one can implement this by storing a config file 
(or config template) at that point in the SVN tree (or some parallel 
tree) and require developers to fetch it and adapt it as their first 
order of business, but a Subversion-provided facility would be 
preferable.  What is the rationale for not storing default props at the 
server?

Joe

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

Re: Migrating repository from Windows to UNIX and eol-style

[Erik Huelsmann <eh...@gmail.com>]

On 7/3/06, Joe <de...@freedomcircle.net> wrote:
> Erik Huelsmann wrote:
> > * Subversion was intentionally designed not to modify files under
> > version control until explicitly told to do so. You may not think your
> > files changed when you want different line-endings, but others may:
> > say you checked in a subversion dump file. If the system started to
> > subsitute line endings for you, the file would have been damaged
> > beyond repair, even though it looked texty. The default is (and
> > *should stay*) to protect your data.
> >
> > Please don't project any problems you may have right this instant on
> > the version control system you're using: your problems are (largely)
> > unrelated to version control, but to inter-OS moving of files.
>
> Thanks Erik.  I can see your point.  However, it is a design decision of
> Subversion to use a heuristic for determining whether something is text
> or not.  Compare that with FTP:  if you transfer in "ASCII" mode it will
> modify a UNIX file and create it with CRLF on Windows, and vice versa,
> i.e., it uses an explicit mode rather than a heuristic.

If I understand you correctly, the above isn't true: Subversion - by
default - doesn't assign meaning to the contents of files being
committed: it doesn't distinguish between text or binary and it
doesn't do eol conversion. That way, the files don't get damaged. When
Subversion would do eol conversion by default, files would get
modified at checkin and there wouldn't be any way to reconstruct the
original. That's why we make it an explicit choice to have eol
conversion.

The only time Subversion uses a heuristic to estimate textiness is
with 'diff' related operations (blame, diff, merge), never with other
situations. BTW: there is no other way to determine whether Subversion
is looking at a text file but to use a heuristic: all files consist of
bytes, the meaning we assign to them is different on a case-by-case
basis (you can just name your JPG images photo.txt, they won't become
text files).

> Since most VCSs
> started being used for storing and controlling program source files, I
> was expecting a similar behavior.

Right. We learned from CVS in this respect: many a time people forgot
to use the 'this is a binary file, please don't modify'-option when
adding an image to the repository. Most of them were damaged,
sometimes not even recoverable (because the original was deleted).

> It still seems to me that forcing clients to deal with auto-props is not
> the best decision since it's too easy to miss a file suffix or have some
> newbie developer in a large mixed-platform group forget to set props and
> start submitting changes and screwing things up (yes, the peers will
> hopefully catch the problem before it gets too far, but IMHO the VCS
> should be preventing this).

Absolutely. This is one of Subversion's weak spots. You as a sysadmin
can prevent the file ending up in the repository by checking for the
right properties and rejecting the 'newbie commit' in a post-commit
hook.

> As I hinted before, I'd prefer a server-based capability that says:  all
> our files are text files and we want to store them at the clients in
> native format and at the server as "collection of logical lines", except
> for files which we specify as binary at the client.  This still would
> allow companies that have mostly binary files to specify otherwise
> (either at the server or the client).

Absolutely. We have had extensive discussion on the development list
about use cases and how the implementation behind this should work.
Especially also how changes in the configuration would propagate. In
the past discussions, we didn't reach a final conclusion of how it
should work though.

If you have resources to spare (time to discuss design or
implementation), you're most welcome to come to dev@ and stirr up the
discussion again. You can read about it all through the mailing list
archives at http://svn.haxx.se/dev/

HTH,


Erik.

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

Re: Migrating repository from Windows to UNIX and eol-style

[Joe <de...@freedomcircle.net>]

Erik Huelsmann wrote:
> * Subversion was intentionally designed not to modify files under
> version control until explicitly told to do so. You may not think your
> files changed when you want different line-endings, but others may:
> say you checked in a subversion dump file. If the system started to
> subsitute line endings for you, the file would have been damaged
> beyond repair, even though it looked texty. The default is (and
> *should stay*) to protect your data.
> 
> Please don't project any problems you may have right this instant on
> the version control system you're using: your problems are (largely)
> unrelated to version control, but to inter-OS moving of files.

Thanks Erik.  I can see your point.  However, it is a design decision of 
Subversion to use a heuristic for determining whether something is text 
or not.  Compare that with FTP:  if you transfer in "ASCII" mode it will 
modify a UNIX file and create it with CRLF on Windows, and vice versa, 
i.e., it uses an explicit mode rather than a heuristic.  Since most VCSs 
started being used for storing and controlling program source files, I 
was expecting a similar behavior.

It still seems to me that forcing clients to deal with auto-props is not 
the best decision since it's too easy to miss a file suffix or have some 
newbie developer in a large mixed-platform group forget to set props and 
start submitting changes and screwing things up (yes, the peers will 
hopefully catch the problem before it gets too far, but IMHO the VCS 
should be preventing this).

As I hinted before, I'd prefer a server-based capability that says:  all 
our files are text files and we want to store them at the clients in 
native format and at the server as "collection of logical lines", except 
for files which we specify as binary at the client.  This still would 
allow companies that have mostly binary files to specify otherwise 
(either at the server or the client).

Joe

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