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

Re: locking a file renders repos unusable with older clients

From: Max Bowsher <maxb_at_ukf.net>
Date: 2005-03-26 00:20:37 CET

Ben Collins-Sussman wrote:
> On Mar 25, 2005, at 10:45 AM, Eric Hanchrow wrote:
>> It looks as if the "svn lock" command has bumped my repository
>> version, and that therefore (short of a dump/reload), I can no longer
>> use my old client with the repository. I realize this is probably by
>> design, and that I'm using dev. code, but I sure would have
>> appreciated, at the very least, a mention of this behavior in
>> .../notes/locking/ or something.
>> In any case, it looks like I now must do "svnadmin dump" and "svnadmin
>> load" in order to recover the ability to use the repository with older
>> clients. Bah.
>> (max bowsher apparently has warned that this would happen, and
>> encouraged me to whine loudly on the -dev list).
> This behavior is the deliberate result of a very long discussion. We
> didn't want older clients using file:/// to ignore locks created by
> newer clients. Therefore, we bumped the repository format number as
> you saw.

But the above misses the point of the complaint.

Whilst I do acknowledge that the "fine print" of our compatibility rules do
allow current trunk behaviour, we've pushed quite hard the concept of "no
dump/loads until 2.0". Allowing someone to accidentally cause their
repository to be incompatibly upgraded is a very bad user experience,
regardless of how big a notice we place in readmes/release notes.

I would like to switch to performing repository upgrades *only* on an
explicit "svnadmin upgrade" (the locking functions would return errors when
running on a non-upgraded repository).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 26 00:22:17 2005

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.