Are commits dangerous?

Former SVN Browser
Posts: 2
Joined: Tue Jul 08, 2008 7:01 pm
Location: Campinas, SP, Brazil

Are commits dangerous?

Postby gnustavo » Tue Aug 05, 2008 12:15 am

Hi there,

We've recently deployed your SVN Web Client to offer an easier way to our users to browse their 200+ repositories. The one feature that set SVN Web Client apart from its competition (SVN::Web, WebSVN, ViewVC) is its ability to commit changes to the repositories through the browser, even though it's just one file at a time.

However, while I was investigating a problem I realized that perhaps this commit feature is too risky to be worthwhile. I'll try to explain why I think this by explaining the test I did and commenting on its failure.

The test was like this:

1) Set up SVN Web Client to browse an existing repository.

2) Checkout part of the repository to a working area using a normal SVN client such as the CLI or TortoiseSVN.

3) Download a file from the repository using SVN Web Client.

4) Edit the same file in both places: the copy in the working area and the copy that was downloaded with SVN Web Client. Make different modifications in each copy.

5) Commit the changed copy in the working area.

6) Commit the downloaded copy that was also changed.

These operations are meant to emulate the work of two people collaborating in a repository: one using a normal SVN client and the other using SVN Web Client.

All the operations went smoothly, with no errors or warnings whatsoever. However, at the end, if you checkout the latest revision of the file (or if you update the working area) you'll notice that it has exactly the same contents as the copy that was downloaded and later edited and committed. All traces of the editions made in the working area were gone.

Now, it may not be obvious at first what is going on here. At least, it wasn't for me.

If both users were using normal SVN clients, step 6 would give an error to the user trying to commit its changes after the other one had already committed his. The error message would say that the "Commit failed" because the file was "Out of date". Subversion would require that the user first update its working area and resolve any conflicts that may arise due to the merging of its modifications with the ones done previously by his colleague. Only then Subversion would allow him to commit his changes.

But why SVN Web Client hasn't caught it? I guess it's because it can't. I haven't dug into the source code to check it (in fact I have, but not long and hard enough to actually find where this things are implemented) but my theory begins by realizing that for SVN Web Client the file that you download is not related in any way with the file that you commit. You don't even *have* to download the file before you try to commit it. The only requirement is that the local file you use to commit has to have the same name of the file in the repository.

Hence, when you commit a file, SVN Web Client cannot check if the file in the repository is still the same as it was when the user downloaded it and started modifying his local copy. Then, later on, when he commits his modified copy, SVN Web Client simply tells Subversion to take it as the newest revision, possibly overriding any intermediary changes introduced by other users.

So, what is it? Can SVN Web Client be changed in order to Do The Right Thing? Or is this really an unavoidable consequence of the difficulties imposed by the three-tiered model used by web apps in general?



Posts: 26
Joined: Fri Sep 16, 2005 12:58 pm
Location: Prague, Czech Republic

Postby chyliko » Fri Aug 08, 2008 12:57 pm

Hi Gustavo,

your observation is absolutely correct.

The "Commit" feature of SVN Web Client simulates the operation of "autoversioning" - the approach where there is virtually no chance to know from where (which revision) the uploaded file comes from.

It is the same thing you could get if using Apache HTTPD to access your repositories, enabling "Autoversioning" in its configuration and then for example connecting the repository as a WebDAV folder.

I realize the management problems this brings to you.

Maybe it would be feasible for you to solve this issue just by training the users -- for example having them take special care when using the Commit feature (like providing an accurate commit message, remember that all the changes can still be seen in the revision history), or simply not using it at all.

I created a tracker item about this topic:

Unfortunately the SVN Web Client project is currently short on resources, so no guarantee can be made as to when this item will be addressed. But since it is an open source project, you are welcome to implement the solution yourself :-) In case you are interested in this option, I would alert the project owners to get in touch with you.

Ondrej Chylik, Polarion Software

Posts: 2
Joined: Tue Jul 08, 2008 7:01 pm
Location: Campinas, SP, Brazil

Postby gnustavo » Fri Aug 08, 2008 3:56 pm

Hi Ondrej. Thank you for your comments.

I didn't know about the "autoversioning" concept. Interesting.

I think there may be scenarious in which the advantages of this feature compensates for its risks. But I'm afraid to leave it available to too many people. I've disabled the feature in our installation.

I have thought about how this could be solved and the only general solution I could come up with would require maintaining too much state on the server running SVN Web Client. I don't think it's worthwhile.

In the end, I think the only "solution" would be along the lines you mentioned: not technical, but processual.


Posts: 4
Joined: Thu Mar 22, 2007 8:04 pm

Re: Are commits dangerous?

Postby kmradke » Wed Jun 24, 2009 4:59 pm

I submitted a patch quite awhile ago that added locking support on a per username basis. Enforcing an user to lock a file before modifying it would help to serialize the changes.

Return to “Polarion SVN Web Client”

Who is online

Users browsing this forum: No registered users and 3 guests