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