> On 24 feb 2014, at 20:36, Ben Reser <ben_at_reser.org> wrote:
>
>> On 2/24/14, 8:30 AM, Thomas Åkesson wrote:
>> We would like to enhance the locking in Subversion to support use cases where the user needs to ensure that added files will be possible to commit. There are a couple of use cases:
>>
>> 1. Adding files that are dependencies to other files, where the reference mechanism is cumbersome. Simple cases include XML files that reference graphics or XIncludes (can be difficult to refactor after a conflict, especially for non-technical users). More complex cases include file formats that are not open and where references are difficult to manage, e.g. MS Word, InDesign, certain modeling tools.
>>
>> 2. There is a standardized naming convention based on series. The next file of a certain type should take the next available number. Then there is a race condition btw different users; how quickly can they finish work and commit after determining the next number and adding to WC.
>>
>> One mapping towards svn usage could be:
>> svn up
>> touch model0018.xml #or create the file with the software.
>> svn add model0018.xml
>> svn lock model0018.xml
>> # invest effort in the new file and potentially link to it from other files.
>> svn commit
>
> Why does doing the following where the empty file is always immediately created
> not work for these use cases:
> svn up
> touch model0018.xml
> svn add model0018.xml
> svn ci -m'Create model0018.xml'
> svn lock model0018.xml
>
> Worst case senario for this seems to be the following.
>
> Alice and Bob are both about to make a new model file. They select the next
> appropriate filename model0018.xml. They both touch and add the file and then
> try to check it in. Alice succeeds, Bob gets a message telling him his commit
> is out of date because Alice won the race. Bob then repeats the steps from the
> top (including selecting the now next available filename).
>
> I'm guessing the answer comes down to user education difficulties.
No. I simplified the use cases, too much obviously.
Let me try again:
svn up
for several hours:
svn add a few files
svn lock those files
work, including linking to those files
revise a bit
review and perhaps svn unlock and svn rm some added files
svn commit
>
>> 3. When there is other software support above svn, it also makes sense to reserve a path via:
>> svn lock http://.../model0018.xml
>> Then performs a programmatic commit that ensures that the lock token is supplied (or svn unlock URL if aborting).
>
> Or maybe I'm missing something since I don't think handling this would be
> difficult in software.
It becomes complicated when:
- we might be talking about a few hundred files, and we would prefer not to commit them one by one (many reasons not to)
- it is desirable to allow the user to review the end result before commit
- I was not only talking about automated selection of file names, could be combinations of manual and series.
- again, links btw the files
Without a locking mechanism, we would basically need a layer of temporary naming and linking that is resolved when attempting to commit, and retried until a commit succeeds without conflict. If we don't have an open file format that we can manipulate, well forget it.
>
>> Current status:
>>
>> Svn does not allow locking non-existent paths. It is blocked both in libsvn_fs_base/libsvn_fs_fs as well as in mod_dav_svn. In the same areas of the code in fs comments say:
>> "While our locking implementation easily supports the locking of
>> nonexistent paths, we deliberately choose not to allow such madness."
>>
>> Given that we now present valid use-cases, it is reassuring that the authors of the locking code said it "easily supports the locking of nonexistent paths".
>>
>> Locking an added file fails using the command line client.
>>
>> In 1.6: svn: warning: W160042: LOCK request on '/svn/repo2/newfile.txt' failed: 405 Method Not Allowed
>>
>> In 1.8: svn: E155010: The node '/Users/.../newfile.txt' was not found.
>
> Yes the existing implementations make this easy to do. But your suggested
> implementation is not the right path to go down.
>
>> There is also a question of how mod_dav_svn should handle "null-locks" when communicating with generic Webdav clients. The WebDAV specification initially proposed support for null-locks but in later revisions moved away from them. I propose to keep the current zero-size-file concept for non-svn clients. There is already a distinction btw svn and non-svn clients in that code, I just tweaked it.
>
> Yes and RFC 4918 killed lock-null resources off for good reason. The whole
> thing was overly complicated, requiring a separate DB on the server side to
> track the non-existent paths it should pretend to exist. Even worse if you
> wanted to support DeltaV you had to keep track of which lock-null resources
> existed when forever. However, if you just created the empty file then all of
> this went away and there was nothing special to handle.
>
> So you can't do what you propose and be RFC4918 compliant. The RFC says that
> locks of non-existent files MUST create the file and removing the lock MUST not
> remove the file.
Well, that is why I propose to stay compliant when talking to a generic webdav client. Lock-null would only be allowed with svn clients. There are other areas where svn clients are deviating from Webdav RFCs, right?
> If we really want to make the UI appear to support locking non-existent files
> we can. There are some issues to work through but I think making the backend
> support locking non-existent files is the wrong approach.
>
> I see two approaches to doing this:
>
> 1) Server supports creating the empty files for the client with the LOCK
> request like we do with auto-versioning clients. This presents problems with
> how the working copy finds out about the new empty file. Since otherwise the
> client will give an out of date error on commit and then the update will have a
> conflict. If we just change the server then old clients talking with such
> servers will suddenly have this problem. Which seems undesirable.
> 2) Have the client create, schedule and commit the new empty file and then
> issue the lock. Essentially doing the steps I presented above for the user
> automatically. This presents the following problems:
>
> a) How does the client know it needs to create the empty file before the lock?
> I'd guess the answer here is that we check if the path exists and try to
> create it. If the wc has the path as already versioned and committed, then
> just try to create the lock (so we fail if you're trying to lock something
> someone has deleted).
>
> b) Does the race condition between two clients trying to lock the same path
> present a problem? Consider that one client is slightly behind another such
> that it runs the check path just as the first client has finished creating the
> file and then the two LOCK requests race. I'm guessing we're not going to be
> happy if the client that created the new file loses that race? For one thing
> the commit message from creating the file might not make sense. I'm guessing
> this could be solved with extending the commit to support a way to lock a file
> iff the commit succeeds. Only newer servers would support this and we could
> decide to allow newer clients with older servers to lock non-existent files
> with the above mentioned known limitations or simply not allow it at all.
>
> It seems to me that 2) is the better approach to me.
None of these approaches address the use-cases when generalised, and these approaches can be accomplished with currently released svn. I probably over-simplified the use cases, sorry about that. I think use-case 1 does to some degree describe the complexity we would like to address.
Regards,
Thomas Å.
Received on 2014-02-25 01:19:07 CET