[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: illegal filename under windows

From: Pflästerer, Karl <Karl.Pflaesterer_at_dfv.de>
Date: Sat, 2 Aug 2014 15:11:28 +0000

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
>> > with that name. I would have expected cleanup to revert a transaction
>> > 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
>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.

Received on 2014-08-02 17:11:58 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.