Am 02.08.14 15:35 schrieb <stsp_at_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.Pflaesterer_at_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
Received on 2014-08-02 17:11:58 CEST