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-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? ;)
Received on 2014-08-02 15:36:07 CEST