Am 02.08.14 15:35 schrieb <s...@elego.de>:
>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-a >ction.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? ;) That sounds really interesting. (I really thought all operations would be in SQL transactions to allow an easy rollback if something goes wrong). But I must say, that at the moment I wouldn’t be a great help. Fortunately at work we have so much to do that I wouldn’t want others waiting for me completing a feature where I couldn’t spend as much time as I liked. Perhaps next year will be a bit more relaxed regarding time. KP
