> -----Original Message-----
> From: Pflästerer, Karl [mailto:Karl.Pflaesterer_at_dfv.de]
> Sent: zaterdag 2 augustus 2014 17:11
> To: Stefan Sperling; Nico Kadel-Garcia
> Cc: users_at_subversion.apache.org
> Subject: Re: illegal filename under windows
>
> 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.
The database updates are in SQL transactions... But what we are talking about here are filesystem operations, which our SQL database can't handle via its transactions.
Inside the SQL transaction we can store workqueue items: Things like: this file must be YYYed, to complete the operation.
YYYed can be something like translated, installed, moved, deleted. etc. But these operations might take a long time and/or might temporary fail, and might be cancelled by the user
The working copy is then in a stable state once the workqueue items are completely handled... 'svn cleanup'-s task it to continue doing the remaining work and then mark the working copy stable again.
In this case this will work against you... as installing the file to an invalid name will fail every time. (Unless you switch operating systems before running cleanup)
Bert
>
> KP
Received on 2014-08-02 19:05:11 CEST