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. It
could work locally, until you do the "svn checkout" under a
multi-platform shared filesystem, like NFS, and expect to use the same
working copy on a more restricted platform, like Windows. I know a
stack of Java developers who do this sort of thing, using their
personal Mac or Windows environments for their favoriter IDE, and
who'd get *really surprised* when their build tools produce different
results on a different platform with the same working copy. And just
wait until some smart aleck uses it to activate local config files
depending on which OS does the checkout and makes the working copy, or
to embed stored credentials in ways that their Windows using boss
won't see in checkout, but they can see on their MacOS or Linux
checkout.
Thee is an obligatory xkcd cartoon about this sort of workflow whackiness:
http://xkcd.com/1172/
Personally, I'd suggest using a pre-commit for multi-platform
environments that says "no OS-incompatible characters in file names!
No! Don't do that No cookie for *you*!" I'd also block the use of
'svn:eol' for similar reasons. It's a much simpler, lighter weight
approach and less likely to destabilizing working software.
In this case in particular, embedding '<>' characteris in a file name
is a great way to break any command line scripting that has to deal
with the files, and should be avoided in filenames on general
principles. Seriously: don't do that. The frase '-to+from-' could be
used to substitute, quite legibly.
Received on 2014-08-02 17:07:08 CEST