You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Eric Hanchrow <of...@blarg.net> on 2005/03/25 16:45:50 UTC
locking a file renders repos unusable with older clients
I've been using 1.1.3 for a long time, and decided to play with
locking a little bit. So I built in trunk (r13638) and did the
following:
$ cd /usr/local/src/svn-live # this is my wc of trunk
$ touch ~/.lock-me
$ /usr/bin/svn add ~/.lock-me
A /home/erich/.lock-me
$ ./svn ci ~/.lock-me -m ""
Adding /home/erich/.lock-me
Transmitting file data .
Committed revision 1596.
$ ./svn lock ~/.lock-me
Waiting for Emacs...
'.lock-me' locked by user 'erich'.
# Oh good, "svn lock" appears to do something.
$ cd
# edit ~/.lock-me some more
$ /usr/bin/svn ci .lock-me # I'm not sure what to expect here; I
# assumed the checkin would complete
# as if the file weren't locked
Waiting for Emacs...
svn: Commit failed (details follow):
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///home/erich/svn-repos/trunk/home'
svn: Expected version '3' of repository; found version '4'
svn: Your commit message was left in a temporary file:
svn: '/home/erich/svn-commit.tmp'
# Hmm, that's an odd error message
$ svn up
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///home/erich/svn-repos/trunk/home'
svn: Expected version '3' of repository; found version '4'
# Oh s****
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).
--
[Dijkstra's] great strength is that he is uncompromising. It
would make him physically ill to think of programming in C++.
-- Donald E. Knuth
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: locking a file renders repos unusable with older clients
Posted by John Pybus <jo...@pybus.org>.
Ben Collins-Sussman wrote:
>
> On Mar 25, 2005, at 5:55 PM, Max Bowsher wrote:
>>
>> I don't understand how the need to run one single quick command can be
>> described as "hassle".
>
> It's a tough call, isn't it?
>
> Is it worse for 5 admins to have to dump & load when they decide to downgrade?
> Or is it worse for 10,000 admins to run 'svnadmin upgrade' to enable locks?
Maybe you underestimate how many people use file:// to access
repositories. I expect the vast majority won't be in scenarios where
locking is important, but I'm a little worried about the possibility of
one attempt to play with the feature leading to a major hassle. Perhaps
you could include a script/tool to downgrade the repository without a
dump and reload.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: locking a file renders repos unusable with older clients
Posted by Norbert Unterberg <ne...@gmx.net>.
Ben Collins-Sussman schrieb:
> Is it worse for 5 admins to have to dump & load when they decide to
> downgrade?
> Or is it worse for 10,000 admins to run 'svnadmin upgrade' to enable locks?
Just my personal opinion on this:
You should look at this issue from a different perspective:
I am tempted think in most cases where network admins are involved
subversion runs on apache or svnserve. On these systems you need to
upgrade the server and then the repository manually to enable locking.
No auto-update here. So 9,500 of the 10,000 admins need to do some
manual work anyway.
But when using subversion on a network share with file:// access (which
is allowed with fsfs, isn't it?) then one person just trying svn 1.2
once might accidentally upgrade the repos and cause problems to all
other members in the team.
I believe enabling locking for a repository (that includes repository
upgrade) should be a concious decision of the development team using
subversion. And the team should have a chance to decide when to upgrade.
There is no auto-update for http: and svn: access methods, and there
should be none for file: access. Only then the point of upgrade can be
postponed until all clients have been upgraded.
The case where automatic update might be ok is when file: access is used
on the local computer. And this is a case where locking might not be
that important.
Ok, just my personal thoughts...
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: locking a file renders repos unusable with older clients
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 25, 2005, at 5:55 PM, Max Bowsher wrote:
>
> I don't understand how the need to run one single quick command can be
> described as "hassle".
It's a tough call, isn't it?
Is it worse for 5 admins to have to dump & load when they decide to
downgrade?
Or is it worse for 10,000 admins to run 'svnadmin upgrade' to enable
locks?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: locking a file renders repos unusable with older clients
Posted by Max Bowsher <ma...@ukf.net>.
Ben Collins-Sussman wrote:
> On Mar 25, 2005, at 5:20 PM, Max Bowsher wrote:
>>
>> But the above misses the point of the complaint.
>
> Actually, I talked to Eric in IRC. The point of his complaint was only
> that he wanted a warning, and would have been happier if the release
> notes had warned. He understands that we don't want older clients
> using file:/// to ignore locks created by newer clients.
>
>>
>> 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.
>
> How about all those times we silently upgraded the wc format?
Never since 1.0.
>> 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).
>>
>
> I thought you and Karl and others had already discussed this...?
But never reached a conclusion.
> While I agree that the scenario described by Eric is a "bad user
> experience", I argue that it's also quite rare -- the rarity comes from
> (1) the use of file:/// and (2) the probablilty of downgrading after
> upgrading.
>
> Meanwhile, balance that option against the "bad user experience" of
> forcing every admin in the universe to run 'svnadmin upgrade' when they
> move to 1.2.
>
> Doesn't the former option seem more friendly to the world? Less hassle
> to fewer people?
I don't understand how the need to run one single quick command can be
described as "hassle".
I think it's simply the polite thing to do to let admins explicitly choose
when to upgrade.
Whereas, the sudden and unplanned need to dump/load to downgrade is a whole
lot of hassle.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: locking a file renders repos unusable with older clients
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2005-03-25 at 18:39, Ben Collins-Sussman wrote:
> Doesn't the former option seem more friendly to the world? Less hassle
> to fewer people?
Yes.
But as I've stated before, I favor not bumping the version at all. So
the current situation is the lesser of two evils for me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: locking a file renders repos unusable with older clients
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 25, 2005, at 5:20 PM, Max Bowsher wrote:
>
> But the above misses the point of the complaint.
Actually, I talked to Eric in IRC. The point of his complaint was only
that he wanted a warning, and would have been happier if the release
notes had warned. He understands that we don't want older clients
using file:/// to ignore locks created by newer clients.
>
> 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.
How about all those times we silently upgraded the wc format?
>
> 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).
>
I thought you and Karl and others had already discussed this...?
While I agree that the scenario described by Eric is a "bad user
experience", I argue that it's also quite rare -- the rarity comes from
(1) the use of file:/// and (2) the probablilty of downgrading after
upgrading.
Meanwhile, balance that option against the "bad user experience" of
forcing every admin in the universe to run 'svnadmin upgrade' when they
move to 1.2.
Doesn't the former option seem more friendly to the world? Less hassle
to fewer people?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: locking a file renders repos unusable with older clients
Posted by Max Bowsher <ma...@ukf.net>.
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
Re: locking a file renders repos unusable with older clients
Posted by Ben Collins-Sussman <su...@collab.net>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org