On Sat, Aug 2, 2014 at 9:35 AM, Stefan Sperling <s...@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.
