On Sat, Aug 02, 2014 at 08:52:19AM -0400, Nico Kadel-Garcia wrote: > On Fri, Aug 1, 2014 at 3:05 AM, Pflästerer, Karl <karl.pflaeste...@dfv.de> > wrote: > > Furthermore: the cleanup command didn’t work because svn could not a file > > with that name. I would have expected cleanup to revert a transaction not > > to complete it. > > Workarounds for system limitations can lead to a lot of complexity in > upstream code can be extraordinarily destabilizing. Patches like that > would have to be done very carefully, and could require extensive > maintenance. Not saying it's not reasonable, but an error in such a > patch could break other working code in other operating systems.
There is a misconception in Karl's question. 'svn cleanup' doesn't deal with transactions. It merely removes working copy locks to make operating on the working copy possible after a buggy or terminally killed client left stale locks. The working copy isn't transactional beyond the transactions sqlite provides and those cannot be rolled back once applied. An update that hasn't finished properly leaves 'incomplete' nodes which must be completed by another update. If a node can't be completed the working copy is in a wedged state. I suppose this is what happened here. >From the design perspective, I suppose we could handle this case with the same approach used for 'server-excluded' and 'not-present' nodes. Subversion's working copy has a concept of 'server-excluded' nodes, i.e. nodes which are technically part of the working copy but were excluded e.g. due to authorization restrictions. If you aren't allowed to see a node in the repository, it won't show up in the working copy, except for a 'server-excluded' node in meta data that reveals the hidden node's name but nothing else. This allows the client to ask for updates to that node in case authorization rules change. 'not-present' nodes are used with mixed-revision working copies where the children of a directory are at a revision in which they don't exist, but their parent directory is at a revision where they do exist. Consider a single-revision working copy at revision 2, where we run: svn rm epsilon/zeta svn commit # committed revision 3 'epsilon' itself remains at revision 2 (if you don't understand why, see http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs ) But epsilon/zeta is at a revision where it was deleted. This is modeled by inserting a 'not-present' node for epsilon/zeta in the nodes table. sqlite> select local_relpath, revision, presence from nodes where local_relpath like '%epsilon%'; local_relpath revision presence ------------- ---------- ---------- epsilon 2 normal epsilon/zeta 3 not-present Perhaps filenames which cannot be represented could be dealt with in a similar way. The node would not show up, and would be 'not-supported' instead of 'incomplete' (note that 'incomplete' is another possible value of the presence column, indicating a node which still needs to be updated). This would certainly have ramifications for existing behaviour and is not a trivial change to make. But I think the idea is worth exploring for someone who has the time and energy for doing so. Perhaps Karl is interested in a side project involving C and sqlite to scratch his own itch? ;)
