On Sat, Aug 02, 2014 at 11:06:41AM -0400, Nico Kadel-Garcia wrote:
> On Sat, Aug 2, 2014 at 9:35 AM, Stefan Sperling <stsp_at_elego.de> wrote:
>
> > '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? ;)
>
> That sounds like a feasible technical solution to the general problem.
>
> I'm concerned that it will contribute to poor or unstable workflow.
That depends on how the client behaves when it encounters the problem.
There is no need for the client to silently gloss over the issue.
Rather than renderung the working copy inoperational, the node can be
recorded, and the client can yell at the user for trying to use a filename
that isn't supported by the local OS. But it could do so in a way that
allows the user to recover from the situation.
The main point of the idea is that the working copy stays operational.
Received on 2014-08-02 17:30:49 CEST