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

Re: WebDav Autoversioning Questions/Problems

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-06-26 19:59:14 CEST

On Jun 25, 2005, at 10:19 AM, Norbert Unterberg wrote:
> But the repository hooks are called, aren't they?

Yep, it's still a 'normal' commit in that sense.

> When you have a ASCII text file in your repository with svn:eol-style
> native, the file is stored internally with LF line endings, right?


> When a user modifies this file using WebDav and manages to put CRLF
> line endings into that file, would a svn client hickup and fail on the
> next checkout, or would the file get the correct line endings on the
> next svn update/commit cycle?

Ooh, yes, I imagine it could definitely cause client failure. If
svn:eol-style=native and the repository (text-base) file has
something other than LF endings, the client tends to choke. We've
seen this happen with cvs2svn.py conversions gone bad... but you're
right, I suspect autoversioning could cause the same problem!

Then again: this just another good reason not to mix 'normal' svn
clients with autoversioning. Not only might this line-ending stuff
get messed up, but it's just dangerous, because there's no real
merging going on. Suppose a normal svn client uploads a new version
of a file, and then 1 second later a DAV client blindly overwrites
it? Sure, locking can prevent that, but in general it seems like a
bad idea to have half your users doing "real" version control with
working-copy merges, and the other half of your users doing blind
overwrites to the repository.

Autoversioning is probably best for teams that are are *only*

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jun 26 20:02:17 2005

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

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