You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2004/10/13 07:34:43 UTC
Locking functional spec: read-only WC
Greg Hudson's directory lock message implicitly brought up the issue with the
working copy being set to read-only. Somehow I missed that in my read of the
docs. So let me add it to the discussion because I'd like to see more
conversation about that.
> 2. Property as communication system
>
> When the Subversion client encounters the "svn:lock" property
> on a path (on checkout or update), it sets the working-copy
> path to a read-only state by default. This serves as a
> reminder to the user that she should lock this path before
> editing it. When a user locks the path, the Subversion
> client fetches the latest version of the file, then makes the
> working-copy path read-write. When the user releases the
> lock, or if the lock is found to be defunct (see next
> section), the Subversion client makes the path read-only
> again.
First off, I think there's a thinko in the last sentence of the paragraph. I
think it should be 'makes the path read-write' not 'read-only.' If there's no
lock present, we're back at our optimistic locking scheme. (And, part of my
dilemma comes from the fact that we're mixing optimistic and pessimistic
locking strategies.) If we don't have a svn:lock set, we're optimistic. But,
what about when it's set? How far do we represent that lock?
I think the idea of mucking with the WC state could be a bad idea. I don't
think the lock state should be implicitly represented within the WC through
the file attributes. A few reasons for this:
1) I view it as the server's job to maintain authoritatively the locks not the
clients. (The owner of the lock obviously needs to store it in *their* WC, so
they have the token.) But, only the server knows whether the lock is still
valid: even the owner's WC may be out-of-date because someone else broke the
lock while they weren't looking.
Think about disconnected operations (big advantage SVN has over CVS, VSS, and
ClearCase): the fact that there was a lock right before I got on a plane to
Boston (which I'll actually be on one in less than 24 hours) doesn't tell me
there is a lock five hours mid-flight. There's no way to know whether a lock
is valid when you are disconnected. It might be valid, or it might not.
What's the point of representing information that could be stale? Why should
we be having stale locks (or already resolved locks) stored in the WC (even if
we don't know they are stale)? I don't see the purpose in being pessimistic
here: it clashes too much with the rest of Subversion.
When I get back and run 'svn up', if I happened to touch a file that was
locked, move my local file over to '.mine' or '.backup' or whatever. And,
mark that I need to do something with it...
2) I view it as a serious impediment to work if I constantly have to deal with
locked files when I already know there's a lock but I want to merge after the
lock is complete. I'd prefer to have knowledge about the lock as deferred or
unobtrusive as possible. Tell me via 'svn info' and 'svn status.' Certainly
don't let me commit without that lock token. Make 'svn up' smart by moving my
local copy to '.mine' or '.backup' when we see that the lock has been released
and the file contents updated. Great, wonderful.
My issue becomes whether the content being locked is ultimately mergable or
not. Some of the intended cases probably aren't mergable (i.e. images).
However, there is a real big case where they *are* mergable: Word docs (in our
group's case, Frame docs and EndNote repositories).
For example, I may know someone else in my group has a lock, but I want to go
ahead and make my changes locally and then I can merge my changes *after*
they've committed and released their lock.
A real common example we have here is that we have a group meeting and we
decide to make a bunch of changes to a document as a result of this meeting.
The tasks are assigned at this meeting. One person needs to restructure the
entire document. And, say, that I am assigned to rewrite one section.
I'd want the person restructuring the document to have a lock until they are
complete with their task as that is the 'most' important one (as judged by
management). Say that person gets back to their office first and runs 'svn
lock'. I went ahead and took a bathroom break and then ran 'svn up' to update
my WC as someone was making some changes right before the meeting, so my
desktop is out-of-date.
Oops, all the files are read-only because there's an outstanding lock. Under
the current proposal, I'd have to go through and make my files readable.
Damn, that's annoying. What I *really* want is to get a R/W copy locally and
*prohibit* my checking it in until the lock is released by the person who
needs to restructure the document. After the lock is released and the file
changed, I now have two copies in my WC: the 'master' version from the
repository with the restructured document and my 'local' copy which has my
smaller (in scope) edits. I'd just want to open both copies, drag the updated
text from my 'backup' over to the 'master', hit save, and be done. Perfect
behavior then.
In closing, I think the tool should prevent me from checking in my changes
without the lock, but it shouldn't obstruct me from modifying my local copy: I
own it and should do whatever I want to it. I look back at how much I hated
RCS's behavior and I don't want to go back to that. I think the WC files
should be read-write at all times and throw messages at the client when they
try to commit to something that has an active lock. But, having read-only WC
files seems like it's going to suck. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Martin Tomes <li...@tomes.org>.
Justin Erenkrantz wrote:
> Greg Hudson's directory lock message implicitly brought up the issue
> with the working copy being set to read-only.
> In closing, I think the tool should prevent me from checking in my
> changes without the lock, but it shouldn't obstruct me from modifying my
> local copy: I own it and should do whatever I want to it. I look back
> at how much I hated RCS's behavior and I don't want to go back to that.
> I think the WC files should be read-write at all times and throw
> messages at the client when they try to commit to something that has an
> active lock. But, having read-only WC files seems like it's going to
> suck. -- justin
I think that the opposing views on read-onlyness of locked files are both valid:-(
I would want to know a file was locked before editing it because I never work disconnected.
Therefore I would like to propose either a client configuration option or a command line option to
svn checkout/update to turn off making locked files read-only.
E.g.:
svn checkout http://... wcname --locked-files-not-readonly
I am sure someone can come up with a better switch name than that:-)
--
Martin Tomes
echo 'martin at tomes x org x uk'\
| sed -e 's/ x /\./g' -e 's/ at /@/'
The Subversion Wiki is at http://www.subversionary.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Folker Schamel <sc...@spinor.com>.
Justin Erenkrantz wrote:
> On Wed, Oct 13, 2004 at 10:56:57AM +0200, Folker Schamel wrote:
>
>>In your scenario, the lock is not used to avoid merge conflicts
>>of unmergeable files (which I think is the primary job of locks),
>>but only to push away the task of merging from me to another person.
>>In your particular scenario: The person restructoring the document:
>>What about simply finishing their task without lock,
>>sending it to management, and then update/merge/commit it?
>
>
> No: there are race conditions without a lock. A SCM with locking makes
> perfect sense in my all-too-common scenario. We don't want to have any lost
> updates because it's not possible for Subversion to merge the changes: merging
> has to be done by a human. Without a lock, there's human race conditions.
- Without lock, there will be a merge conflict in the other guy's
working copy, because of your commit.
- With a lock but rw wc file, there will be a merge conflict
in your working copy because you changed the file locally.
- With a lock but read-only wc file, there won't be a merge conflict at all,
because you were not able to modify the file.
Agreed, there may be cases that you might still want to change your
file locally even if someone else has a lock.
Similar to stealing a lock.
But you can simply change the file attribute for that,
so I don't see a problem.
I think the main reason for locks is to avoid (unmergable) conflicts,
and a read-only wc file is important for that.
If you and others don't want/need write protection,
an option may be the right choice.
But I am sure that if locking does not support read-only wc files at all,
this would be a fundamental flaw.
Cheers,
Folker
>
> The point of the lock is to prevent anyone from making changes. The question
> I fundamentally have is: where are we trying to prevent those changes?
>
> Are we trying to prevent:
>
> - The user from making any local changes
> or
> - The repository from having any unanticipated changes
>
> I fall on the latter side and that Subversion shouldn't interfere with
> whatever the local WC does. Subversion shouldn't be my nanny. -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Oct 13, 2004 at 10:56:57AM +0200, Folker Schamel wrote:
> In your scenario, the lock is not used to avoid merge conflicts
> of unmergeable files (which I think is the primary job of locks),
> but only to push away the task of merging from me to another person.
> In your particular scenario: The person restructoring the document:
> What about simply finishing their task without lock,
> sending it to management, and then update/merge/commit it?
No: there are race conditions without a lock. A SCM with locking makes
perfect sense in my all-too-common scenario. We don't want to have any lost
updates because it's not possible for Subversion to merge the changes: merging
has to be done by a human. Without a lock, there's human race conditions.
The point of the lock is to prevent anyone from making changes. The question
I fundamentally have is: where are we trying to prevent those changes?
Are we trying to prevent:
- The user from making any local changes
or
- The repository from having any unanticipated changes
I fall on the latter side and that Subversion shouldn't interfere with
whatever the local WC does. Subversion shouldn't be my nanny. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Folker Schamel <sc...@spinor.com>.
Justin Erenkrantz wrote:
> Greg Hudson's directory lock message implicitly brought up the issue
> with the working copy being set to read-only. Somehow I missed that in
> my read of the docs. So let me add it to the discussion because I'd
> like to see more conversation about that.
>
>> 2. Property as communication system
>>
>> When the Subversion client encounters the "svn:lock" property
>> on a path (on checkout or update), it sets the working-copy
>> path to a read-only state by default. This serves as a
>> reminder to the user that she should lock this path before
>> editing it. When a user locks the path, the Subversion
>> client fetches the latest version of the file, then makes the
>> working-copy path read-write. When the user releases the
>> lock, or if the lock is found to be defunct (see next
>> section), the Subversion client makes the path read-only
>> again.
>
>
> First off, I think there's a thinko in the last sentence of the
> paragraph. I think it should be 'makes the path read-write' not
> 'read-only.' If there's no lock present, we're back at our optimistic
> locking scheme. (And, part of my dilemma comes from the fact that we're
> mixing optimistic and pessimistic locking strategies.) If we don't have
> a svn:lock set, we're optimistic. But, what about when it's set? How
> far do we represent that lock?
>
> I think the idea of mucking with the WC state could be a bad idea. I
> don't think the lock state should be implicitly represented within the
> WC through the file attributes. A few reasons for this:
>
> 1) I view it as the server's job to maintain authoritatively the locks
> not the clients. (The owner of the lock obviously needs to store it in
> *their* WC, so they have the token.) But, only the server knows whether
> the lock is still valid: even the owner's WC may be out-of-date because
> someone else broke the lock while they weren't looking.
>
> Think about disconnected operations (big advantage SVN has over CVS,
> VSS, and ClearCase): the fact that there was a lock right before I got
> on a plane to Boston (which I'll actually be on one in less than 24
> hours) doesn't tell me there is a lock five hours mid-flight. There's
> no way to know whether a lock is valid when you are disconnected. It
> might be valid, or it might not. What's the point of representing
> information that could be stale? Why should we be having stale locks
> (or already resolved locks) stored in the WC (even if we don't know they
> are stale)? I don't see the purpose in being pessimistic here: it
> clashes too much with the rest of Subversion.
>
> When I get back and run 'svn up', if I happened to touch a file that was
> locked, move my local file over to '.mine' or '.backup' or whatever.
> And, mark that I need to do something with it...
>
> 2) I view it as a serious impediment to work if I constantly have to
> deal with locked files when I already know there's a lock but I want to
> merge after the lock is complete. I'd prefer to have knowledge about
> the lock as deferred or unobtrusive as possible. Tell me via 'svn info'
> and 'svn status.' Certainly don't let me commit without that lock
> token. Make 'svn up' smart by moving my local copy to '.mine' or
> '.backup' when we see that the lock has been released and the file
> contents updated. Great, wonderful.
>
> My issue becomes whether the content being locked is ultimately mergable
> or not. Some of the intended cases probably aren't mergable (i.e.
> images). However, there is a real big case where they *are* mergable:
> Word docs (in our group's case, Frame docs and EndNote repositories).
>
> For example, I may know someone else in my group has a lock, but I want
> to go ahead and make my changes locally and then I can merge my changes
> *after* they've committed and released their lock.
>
> A real common example we have here is that we have a group meeting and
> we decide to make a bunch of changes to a document as a result of this
> meeting. The tasks are assigned at this meeting. One person needs to
> restructure the entire document. And, say, that I am assigned to
> rewrite one section.
>
> I'd want the person restructuring the document to have a lock until they
> are complete with their task as that is the 'most' important one (as
> judged by management). Say that person gets back to their office first
> and runs 'svn lock'. I went ahead and took a bathroom break and then
> ran 'svn up' to update my WC as someone was making some changes right
> before the meeting, so my desktop is out-of-date.
>
> Oops, all the files are read-only because there's an outstanding lock.
> Under the current proposal, I'd have to go through and make my files
> readable. Damn, that's annoying. What I *really* want is to get a R/W
> copy locally and *prohibit* my checking it in until the lock is released
> by the person who needs to restructure the document. After the lock is
> released and the file changed, I now have two copies in my WC: the
> 'master' version from the repository with the restructured document and
> my 'local' copy which has my smaller (in scope) edits. I'd just want to
> open both copies, drag the updated text from my 'backup' over to the
> 'master', hit save, and be done. Perfect behavior then.
>
> In closing, I think the tool should prevent me from checking in my
> changes without the lock, but it shouldn't obstruct me from modifying my
> local copy: I own it and should do whatever I want to it. I look back
> at how much I hated RCS's behavior and I don't want to go back to that.
> I think the WC files should be read-write at all times and throw
> messages at the client when they try to commit to something that has an
> active lock. But, having read-only WC files seems like it's going to
> suck. -- justin
In your scenario, the lock is not used to avoid merge conflicts
of unmergeable files (which I think is the primary job of locks),
but only to push away the task of merging from me to another person.
In your particular scenario: The person restructoring the document:
What about simply finishing their task without lock,
sending it to management, and then update/merge/commit it?
In my opinion, if files can be modified locally but cannot be merged,
then locking would be more or less useless, because it fails
the job of avoiding merge conflicts of unmergable files.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Oct 14, 2004, at 11:46 PM, Justin Erenkrantz wrote:
> --On Wednesday, October 13, 2004 8:57 PM -0400 Garrett Rooney
> <ro...@electricjellyfish.net> wrote:
>
>> lock, which the svn:must-lock property will provide, or not do it at
>> all. I
>> don't like the inconsistency presented by having things magically
>> becoming
>> read-only based on whether I've run 'svn update'. It just feels
>> wrong. I'd
>> prefer to go either all one way or all the other, on a per-file basis,
>> controlled by the property.
>
> +1. -- justin
I'm inclined to agree. This would enable us to keep the communication
mechanism (the property) apart from the locking action ('svn lock' and
friends).
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, October 13, 2004 8:57 PM -0400 Garrett Rooney
<ro...@electricjellyfish.net> wrote:
> lock, which the svn:must-lock property will provide, or not do it at all. I
> don't like the inconsistency presented by having things magically becoming
> read-only based on whether I've run 'svn update'. It just feels wrong. I'd
> prefer to go either all one way or all the other, on a per-file basis,
> controlled by the property.
+1. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Jack Repenning wrote:
> I'm not sure about one thing, though: if there's no property, and if yet
> there's a lock, then does checkout/update (by someone not the locker)
> read-only-ate the file, as is done when the property is set? As nearly
> as I can see, locking-ui.txt does not say so (I would assume, then, the
> answer to be "no"). But it seems to me that the presence of an actual
> lock, regardless of the "svn:must-lock" property, should force some
> additional discipline about the file.
>
> In other contexts, we sometimes talk about "advisory" vs. "compulsory"
> locks, where "advisory" locks only get in the way of people nice enough
> to check for them. Without the enforcement mentioned immediately above,
> these seem to be purely advisory locks (for files without the property,
> anyway)?
I don't like the idea of turning files read only like that. It seems
like we should either force the file to be read-only whenever you don't
have the lock, which the svn:must-lock property will provide, or not do
it at all. I don't like the inconsistency presented by having things
magically becoming read-only based on whether I've run 'svn update'. It
just feels wrong. I'd prefer to go either all one way or all the other,
on a per-file basis, controlled by the property.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Jack Repenning <jr...@collab.net>.
On Oct 13, 2004, at 8:32 AM, Justin Erenkrantz wrote:
> On Wed, Oct 13, 2004 at 09:09:19AM -0400, Greg Hudson wrote:
>> I think you're missing a fundamental aspect of the locking design.
>> The
>> svn:lock property does not mean the file is locked; it means the file
>> *must be* locked before editing. Locks themselves are not represented
>> by properties. The working copy will learn about contention when it
>> tries to get the lock.
>
> Uh, then, I don't think that's such a good idea. Locks really should
> not have
> to be pre-declared. I should be able to lock any file at any time.
You can. The property causes commit to do the integrity check "is the
file already locked?" But regardless of whether the property is
present or not,
- you can lock the file
- your lock prevents anyone else from locking
I'm not sure about one thing, though: if there's no property, and if
yet there's a lock, then does checkout/update (by someone not the
locker) read-only-ate the file, as is done when the property is set?
As nearly as I can see, locking-ui.txt does not say so (I would assume,
then, the answer to be "no"). But it seems to me that the presence of
an actual lock, regardless of the "svn:must-lock" property, should
force some additional discipline about the file.
In other contexts, we sometimes talk about "advisory" vs. "compulsory"
locks, where "advisory" locks only get in the way of people nice enough
to check for them. Without the enforcement mentioned immediately
above, these seem to be purely advisory locks (for files without the
property, anyway)?
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: +1 650.228.2562
c: +1 408.835.8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Justin Erenkrantz wrote:
> Or, are you saying that I could also have a
> lock on a file that doesn't have the svn:lock property set? If so, that
> certainly wasn't clear. And, if that's the case, I'd rename svn:lock to
> 'svn:mandatory-lock' or something. -- justin
I believe that is what they are saying, and I agree, it should be
renamed to 'svn:must-lock' or something like that. I was confused by
the 'svn:lock' name as well.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Oct 13, 2004 at 09:09:19AM -0400, Greg Hudson wrote:
> I think you're missing a fundamental aspect of the locking design. The
> svn:lock property does not mean the file is locked; it means the file
> *must be* locked before editing. Locks themselves are not represented
> by properties. The working copy will learn about contention when it
> tries to get the lock.
Uh, then, I don't think that's such a good idea. Locks really should not have
to be pre-declared. I should be able to lock any file at any time.
(FWIW, the locking UI doc doesn't really make this clear. I guess Ben thought
that, but I don't think it comes across from the doc unless you already
know that is how it works. This is certainly very different from our
previous locking strategies.)
> So the working copy does not have to know whether anyone else has a lock
> on the file. It only has to know whether itself has a lock, which is
> easy.
The model I am thinking of here is Dreamweaver's locking system. A file may
be in one of two states:
- No lock is present
- File is locked and someone holds it
Any file at any time can be locked. Forcing a pre-declaration seems really
odd. What's the justification? Or, are you saying that I could also have a
lock on a file that doesn't have the svn:lock property set? If so, that
certainly wasn't clear. And, if that's the case, I'd rename svn:lock to
'svn:mandatory-lock' or something. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Simon Large <sl...@blazepoint.co.uk>.
"Ph. Marek" wrote
> > to produce a merge tool for every imaginable file type, in practice
most
> > people don't have them, which is why they want locking.
> That's true. But I don't think you're able to modify MSWord-Files
without
> Microsoft Office (or KOffice, or OpenOffice, etc.) ... so it seems
reasonable
> to have the tools that are needed for my work available.
Editing and merging are different. I can edit any text format file with
notepad, but non-trivial merging (which is where I started out) is
format-dependent.
> If I need a special program to edit file X (image manipulation, some
kind of
> office, ... even .tar-files would be possible) AND I'd like to do
version
> controlling AND I'd like to have parallel editing THEN I'll need some
tool to
> merge, or I'll have to do the merge by hand.
Agreed
> I'm aware that it won't be possible to have every merge program
available
> everywhere ... all I'd like to get through is there should be a
possibility
> to call external programs depending on the mime-type for merge and
diff.
> BUT: I need some tools to modify some data - I *should* be allowed to
get the
> corresponding merge tools, if there are any.
So what you are asking for is a client-side config file which determines
the merge tool to use, based on mime-type. Isn't that a separate feature
request? I don't think it affects the arguments about locking
strategies.
> Locking is needed - for file-formats which have no merge tools
(installed), or
Agreed. All I was saying was that some text files which can normally be
trivially merged automatically without any special merge tool (C source,
xml, text, etc), are difficult in *some* circumstances. And in those
cases, locking would be useful, but hard to implement as a
'svn:lock-sometimes'.
>... possibly we could burn the "don't
> modify tags"-problem here too - just lock
> the /tags/xxx-directory-tree ... :-)
... and that is another story ;-)
But I think we are making a lot of noise on the dev list without
actually contributing much to the problem in hand ;-)
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
> > some such) and then svn should do the merge by using a special program
> Sorry, that argument won't wash. While it may be theoretically possible
> to produce a merge tool for every imaginable file type, in practice most
> people don't have them, which is why they want locking.
That's true. But I don't think you're able to modify MSWord-Files without
Microsoft Office (or KOffice, or OpenOffice, etc.) ... so it seems reasonable
to have the tools that are needed for my work available.
Even MSWord has a feature which claims to merge two word files (although I've
never tested, of course)
So, to get back:
If I need a special program to edit file X (image manipulation, some kind of
office, ... even .tar-files would be possible) AND I'd like to do version
controlling AND I'd like to have parallel editing THEN I'll need some tool to
merge, or I'll have to do the merge by hand.
I'm aware that it won't be possible to have every merge program available
everywhere ... all I'd like to get through is there should be a possibility
to call external programs depending on the mime-type for merge and diff.
> Also, the whole point about using text-based files format is that they
> are easy to edit using any text editor, which makes them accessible to
> anyone. Relying on special purpose merge tools negates that
> accessibility.
That's correct.
> However, over a period of time the indentation
> had become completely messed up, and some of the text required
> re-wrapping to fit a sensible width.
But "any text editor" (which I take to be eg. notepad) doesn't do this :-)
Of course, I buy your point.
BUT: I need some tools to modify some data - I *should* be allowed to get the
corresponding merge tools, if there are any.
Locking is needed - for file-formats which have no merge tools (installed), or
when a path should not be changed ... possibly we could burn the "don't
modify tags"-problem here too - just lock
the /tags/xxx-directory-tree ... :-)
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Simon Large <sl...@blazepoint.co.uk>.
"Ph. Marek" wrote:
> > text files which are normally mergeable can sometimes be
> > modified in hard-to-merge ways.
> But that depends entirely on the merge-tools.
> Your example given I'd expect the file to have a mime-type of text/xml
(or
> some such) and then svn should do the merge by using a special program
for
> xml.
>
> To be honest, I'd believe even tiff-pictures to be mergeable using the
correct
> algorithms and programs - eg. by dumping them in ppm(5) format with
every
> pixel on its line ...
Sorry, that argument won't wash. While it may be theoretically possible
to produce a merge tool for every imaginable file type, in practice most
people don't have them, which is why they want locking.
Also, the whole point about using text-based files format is that they
are easy to edit using any text editor, which makes them accessible to
anyone. Relying on special purpose merge tools negates that
accessibility.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Thursday 14 October 2004 10:46, Simon Large wrote:
> Please excuse my butting in on this thread, but I would like to point
> out that text files which are normally mergeable can sometimes be
> modified in hard-to-merge ways. I can give you a case in point from a
> couple of days ago:
>
> The TSVN documentation is in XML and normally changes can be merged
> efficiently and easily. However, over a period of time the indentation
> had become completely messed up, and some of the text required
> re-wrapping to fit a sensible width.
...
> Sorry, no solutions, only problems. Just pointing out that mergeable
> files ain't necessarily so.
IMO the problem is that
> text files which are normally mergeable can sometimes be
> modified in hard-to-merge ways.
But that depends entirely on the merge-tools.
Your example given I'd expect the file to have a mime-type of text/xml (or
some such) and then svn should do the merge by using a special program for
xml.
(In the simplest case, drop all whitespace, merge them afterwards, and
re-insert whitespace on the right positions - like the various
auto-indentation-tools do)
So, to get back to your original end-statement:
> Just pointing out that mergeable
> files ain't necessarily so.
To be honest, I'd believe even tiff-pictures to be mergeable using the correct
algorithms and programs - eg. by dumping them in ppm(5) format with every
pixel on its line ...
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Jack Repenning <jr...@collab.net>.
On Oct 13, 2004, at 11:35 AM, Ben Collins-Sussman wrote:
>
> On Oct 13, 2004, at 12:01 PM, John Peacock wrote:
>
>>
>> I can see the utility for non-mergeable files of forcing the lock to
>> be obtained in advance of the commit (and I've reread the Hijack
>> section again now ;). But if we are to permit locking of files
>> without setting the flag, how is that going to facilitate
>> communicating that the file is locked now?
>>
>
> It's not important that locking communication be "good" in the case of
> mergeable files. Why? Because the file is mergable. Suppose you
> lock foo.c and I'm unaware of this. Then I edit foo.c and my commit
> fails. My work is 'wasted'. I run 'svn up', merge things, then
> eventually commit after you release the lock.
>
> The whole point of the 'svn:needs-lock'/read-only communication system
> is that it prevents people from writing *unmergeable* changes.
Mergeability is not solely about file type.
If I'm checking out a file to change its indentation style, or to
switch all the identifiers from_underscored_words toCamelCase (and my
hands remain upon my wrists...), these changes are likely to be
unmergeable.
Changes to APIs provide a different use case for locking, having not so
much to do with mergeability as change control (well, you can do a
*really* abstract sort of idea of mergeability here...).
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: +1 650.228.2562
c: +1 408.835.8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by John Peacock <jp...@rowman.com>.
Ben Collins-Sussman wrote:
> Oy, inherited properties?? Now you've spun us off into a whole new
> dimension of complexity!
How better to handle directory locking? I'm not saying that we have to
go that direction initially, but rather that the possibility shouldn't
be ignored in the design phase, just because we are not ready to
implement it immediately.
As long as the client code is completely ignorant of what is going on
with the server:
CLIENT: is this file locked?
SERVER: No, and here is a lock token!
or
CLIENT: is this file locked?
SERVER: No and the admin told me you cannot lock it!
then how it is actually stored in the repository is much more flexible.
Now, it is a property associate with each and every file in a
directory; later, it could be an inherited property associated with the
containing directory.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 13, 2004, at 2:35 PM, Ben Collins-Sussman wrote:
>>
>
> It's not important that locking communication be "good" in the case of
> mergeable files. Why? Because the file is mergable. Suppose you
> lock foo.c and I'm unaware of this. Then I edit foo.c and my commit
> fails. My work is 'wasted'.
Whoops, I meant, "my work *isn't* wasted", because I can still merge it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Simon Large <sl...@blazepoint.co.uk>.
"Michael Brouwer" wrote
> Of course that particular problem would be better solved by a better
> diff3 type algorithm that can deal with indentation changes rather
than
> file locking. After all locking doesn't solve the problem of wanting
> to merge branches or even patches applied in the past.
Yes, there are various other solutions to that *particular* problem. The
point I am making is that in the general case, there will always be
occasional unmergeable (well, hard-to-merge anyway) changes in what is
normally a straightforward file. You can't include a merge algorithm to
suit every occasion.
But locking in this case is probably too difficult anyway.
Mandatory-lock and no-lock is OK, but sometimes-lock is much harder.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Michael Brouwer <mi...@tlaloc.net>.
Of course that particular problem would be better solved by a better
diff3 type algorithm that can deal with indentation changes rather than
file locking. After all locking doesn't solve the problem of wanting
to merge branches or even patches applied in the past.
something like svn merge --ignore-indentation-changes would be a better
way to go here.
Michael
On Oct 14, 2004, at 1:46 AM, Simon Large wrote:
> "Ben Collins-Sussman" wrote
>> It's not important that locking communication be "good" in the case of
>> mergeable files. Why? Because the file is mergable. Suppose you
> lock
>> foo.c and I'm unaware of this. Then I edit foo.c and my commit fails.
>> My work isn't 'wasted'. I run 'svn up', merge things, then eventually
>> commit after you release the lock.
>
> Please excuse my butting in on this thread, but I would like to point
> out that text files which are normally mergeable can sometimes be
> modified in hard-to-merge ways. I can give you a case in point from a
> couple of days ago:
>
> The TSVN documentation is in XML and normally changes can be merged
> efficiently and easily. However, over a period of time the indentation
> had become completely messed up, and some of the text required
> re-wrapping to fit a sensible width.
>
> This makes changes to a large number of lines in the file, and it also
> means that any changes by someone else in the same area (and this did
> happen) generate huge numbers of conflicts which can only be merged by
> careful hand editing. It's still mergeable, it's just *much* harder
> than
> usual.
>
> Of course, locking the file when locking is normally not required does
> not solve the problem. No-one else has read-only copies, so they could
> have started editing before I acquired the lock. Or, after the lock is
> released, they might start editing an older version of the file without
> updating. Good old-fashioned talking works better here ("don't edit
> this
> file yet, and update after I commit my changes").
>
> Sorry, no solutions, only problems. Just pointing out that mergeable
> files ain't necessarily so.
>
> Simon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Simon Large <sl...@blazepoint.co.uk>.
"Ben Collins-Sussman" wrote
> It's not important that locking communication be "good" in the case of
> mergeable files. Why? Because the file is mergable. Suppose you
lock
> foo.c and I'm unaware of this. Then I edit foo.c and my commit fails.
> My work isn't 'wasted'. I run 'svn up', merge things, then eventually
> commit after you release the lock.
Please excuse my butting in on this thread, but I would like to point
out that text files which are normally mergeable can sometimes be
modified in hard-to-merge ways. I can give you a case in point from a
couple of days ago:
The TSVN documentation is in XML and normally changes can be merged
efficiently and easily. However, over a period of time the indentation
had become completely messed up, and some of the text required
re-wrapping to fit a sensible width.
This makes changes to a large number of lines in the file, and it also
means that any changes by someone else in the same area (and this did
happen) generate huge numbers of conflicts which can only be merged by
careful hand editing. It's still mergeable, it's just *much* harder than
usual.
Of course, locking the file when locking is normally not required does
not solve the problem. No-one else has read-only copies, so they could
have started editing before I acquired the lock. Or, after the lock is
released, they might start editing an older version of the file without
updating. Good old-fashioned talking works better here ("don't edit this
file yet, and update after I commit my changes").
Sorry, no solutions, only problems. Just pointing out that mergeable
files ain't necessarily so.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 13, 2004, at 12:01 PM, John Peacock wrote:
> Ben Collins-Sussman wrote:
>
>> Suppose somebody tries to commit a hijacked file that has the
>> 'svn:must-lock' property attached. My instinct is that they get an
>> error saying "get a lock first!", regardless of whether someone has
>> already locked the file or not. This teaches the user to stop
>> hijacking.
>
> Perhaps the conceptual thing I am stuck on is that file/directory
> locking can happen without the svn:lock property being set. Here, the
> WC has no notion that the file is locked until commit time, which
> violates the goal in I.A.2. to provide a communication mechanism to
> prevent needless editing which will be blocked by locks.
Correct. If you choose to lock an ordinary mergable file, like a C
file, then presumably there's no way I'd know about it, other than
- running 'svn st -u'
- seeing an email from the post-lock hook script
>
> I can see the utility for non-mergeable files of forcing the lock to
> be obtained in advance of the commit (and I've reread the Hijack
> section again now ;). But if we are to permit locking of files
> without setting the flag, how is that going to facilitate
> communicating that the file is locked now?
>
It's not important that locking communication be "good" in the case of
mergeable files. Why? Because the file is mergable. Suppose you lock
foo.c and I'm unaware of this. Then I edit foo.c and my commit fails.
My work is 'wasted'. I run 'svn up', merge things, then eventually
commit after you release the lock.
The whole point of the 'svn:needs-lock'/read-only communication system
is that it prevents people from writing *unmergeable* changes.
So I don't feel like there's a problem that needs solving here.
> What we really need is not a flag but a tri-state:
>
> 1) this file must be locked before editing (binary/non-mergeable)
> 2) this file can be locked (mergeable files)
> 3) this file cannot be locked
>
> then this would fit all of our needs. People who don't want to permit
> locking set #3 at the root of the repository (and all files would
> inherit it). The normal state would be #2 (matching the current
> behavior, mostly), and the exceptional case would be #1.
Oy, inherited properties?? Now you've spun us off into a whole new
dimension of complexity!
Why is case #3 needed at all? If an admin is morally opposed to
locking of any kind, then just set the 'pre-lock' hook script to always
return failure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by John Peacock <jp...@rowman.com>.
Ben Collins-Sussman wrote:
> Suppose somebody tries to commit a hijacked file that has the
> 'svn:must-lock' property attached. My instinct is that they get an
> error saying "get a lock first!", regardless of whether someone has
> already locked the file or not. This teaches the user to stop hijacking.
Perhaps the conceptual thing I am stuck on is that file/directory
locking can happen without the svn:lock property being set. Here, the
WC has no notion that the file is locked until commit time, which
violates the goal in I.A.2. to provide a communication mechanism to
prevent needless editing which will be blocked by locks.
I can see the utility for non-mergeable files of forcing the lock to be
obtained in advance of the commit (and I've reread the Hijack section
again now ;). But if we are to permit locking of files without setting
the flag, how is that going to facilitate communicating that the file is
locked now?
What we really need is not a flag but a tri-state:
1) this file must be locked before editing (binary/non-mergeable)
2) this file can be locked (mergeable files)
3) this file cannot be locked
then this would fit all of our needs. People who don't want to permit
locking set #3 at the root of the repository (and all files would
inherit it). The normal state would be #2 (matching the current
behavior, mostly), and the exceptional case would be #1.
What I was thinking about for inherited properties would fit neatly into
this model:
1) when checking out a file, the server would send additional properties
based on the inherited state at that point (to allow for checkouts at
different revisions); this could include
svn:lock,
svn:property:customprop,
or any other inherited property; as stored in the repository, the
attribute could be at the file or directory level and the server would
be responsible for walking the tree to determine the current state.
2) when the WC is updated, the server would treat changes in inherited
properties as updates (so a new lock would suddenly show up on a file),
and "svn st -u" would report the same information.
3) the WC would maintain a list of properties (both real and inherited)
at the rev of last update, and behave appropriately (whether that would
be expanding custom keywords or setting the WC file to be readonly when
a lock is initiated).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 13, 2004, at 10:31 AM, John Peacock wrote:
> Ben Collins-Sussman wrote:
>
>> There are two scenarios here:
>> 1. An admin wisely puts an 'svn:lock' property on an image file.
>> This means that the file is read-only most of the time, and users
>> *must* obtain a lock before they can start editing; this prevents
>> people from wasting time on unmergeable changes.
>
> Except that by relying on the filesystem r/w attribute, we cannot
> completely prevent users from flipping that bit without using a
> Subversion client to obtain a lock. Subversion does not provide an
> IDE and we don't have the luxury of hooks into the editor to mediate
> all access to version controlled files.
Right, this is the "hijack" scenario discussed in the UI spec. The
same scenario that VSS and Clearcase have to deal with from
time-to-time.
>
> The lock is still only truly enforced when trying to commit, so I
> think the client needs to behave appropriately when attempting to
> commit a file with svn:lock set without having previously obtained a
> lock. What I'd prefer to what's in locking-ui.txt:
>
> a) the file is not already locked, so a lock is created, the file
> committed, and the lock released (I'd also like to see it throw a
> warning here);
>
> b) alternatively, even if the file is not already locked, the server
> could require a lock to be obtained as an independent step before
> permitting the commit (I would suggest this be an administrative
> option);
>
> c) the file _is_ locked, so the commit fails with an appropriate error
> message - "You DOPE! You need to get a lock first!" ;)
I'm not sure we need to get so complex here, or create so many
configurable options.
Suppose somebody tries to commit a hijacked file that has the
'svn:must-lock' property attached. My instinct is that they get an
error saying "get a lock first!", regardless of whether someone has
already locked the file or not. This teaches the user to stop
hijacking.
If, after getting a lock, the file is out-of-date, then the client
tells the user to run 'update'. If the update would result in a
conflict (most likely, since an 'svn:must-lock' property probably means
the file is unmergeable), then the client does the "wussy conflict
resolution" thing: prints a warning and drops the repos file into a
backup file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by John Peacock <jp...@rowman.com>.
Ben Collins-Sussman wrote:
> There are two scenarios here:
>
> 1. An admin wisely puts an 'svn:lock' property on an image file.
>
> This means that the file is read-only most of the time, and users
> *must* obtain a lock before they can start editing; this prevents
> people from wasting time on unmergeable changes.
Except that by relying on the filesystem r/w attribute, we cannot
completely prevent users from flipping that bit without using a
Subversion client to obtain a lock. Subversion does not provide an IDE
and we don't have the luxury of hooks into the editor to mediate all
access to version controlled files.
The lock is still only truly enforced when trying to commit, so I think
the client needs to behave appropriately when attempting to commit a
file with svn:lock set without having previously obtained a lock. What
I'd prefer to what's in locking-ui.txt:
a) the file is not already locked, so a lock is created, the file
committed, and the lock released (I'd also like to see it throw a
warning here);
b) alternatively, even if the file is not already locked, the server
could require a lock to be obtained as an independent step before
permitting the commit (I would suggest this be an administrative option);
c) the file _is_ locked, so the commit fails with an appropriate error
message - "You DOPE! You need to get a lock first!" ;)
Case a) would work like the current non-locking behavior in a completely
transparent fashion and I'd personally use that in preference to b).
Perhaps the value of svn:lock could determine which mode:
svn:lock = 0 or null - lock must be proactively present before any
commit on this file is possible
svn:lock = 1 - existing lock will block commits, but otherwise an atomic
commit will be lock => commit => unlock
svn:lock = 2 - signed note from your mom required for commit ;)
>
> 2. Justin's team is collaborating on a mergeable text file.
>
> This file would have so such 'svn:lock' property or resultant
> read-only attribute.
I think you mean "no such" here.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 13, 2004, at 9:09 AM, Greg Hudson wrote:
> I think you're missing a fundamental aspect of the locking design. The
> svn:lock property does not mean the file is locked; it means the file
> *must be* locked before editing. Locks themselves are not represented
> by properties. The working copy will learn about contention when it
> tries to get the lock.
>
> So the working copy does not have to know whether anyone else has a
> lock
> on the file. It only has to know whether itself has a lock, which is
> easy.
>
Thanks for saying this, Greg. I was about to write the same thing to
Justin. :-)
There are two scenarios here:
1. An admin wisely puts an 'svn:lock' property on an image file.
This means that the file is read-only most of the time, and users
*must* obtain a lock before they can start editing; this prevents
people from wasting time on unmergeable changes.
2. Justin's team is collaborating on a mergeable text file.
This file would have so such 'svn:lock' property or resultant
read-only attribute. It's still lockable by anyone, and the lock is
still enforced by the server at commit-time. But folks are still free
to concurrently edit local copies, even when somebody has locked it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: read-only WC
Posted by Greg Hudson <gh...@MIT.EDU>.
I think you're missing a fundamental aspect of the locking design. The
svn:lock property does not mean the file is locked; it means the file
*must be* locked before editing. Locks themselves are not represented
by properties. The working copy will learn about contention when it
tries to get the lock.
So the working copy does not have to know whether anyone else has a lock
on the file. It only has to know whether itself has a lock, which is
easy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org