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

Re: Yet another Case-Insensitive File System Problem

From: John Peacock <jpeacock_at_rowman.com>
Date: 2003-07-30 19:16:20 CEST

Branko Čibej wrote:

> Huh? This would "solve" your particular problem, but would cause any
> number of new ones. What if the directories are totally unrelated?

If there was a way to say, 'svn co --ignore=this/Stupid/dIrectory' then I could
get around the problem directory. Yes, I know I could build a series of
non-recursive checkouts that would have the appropriate effect. It would be
very painful.

Or, an option to have svn only warn (and then skip) when there are conflicting
directory names, so at least the wc is consistent (no merged directories). Or
even prompt and say "I can give you either path/to/dir or path/to/Dir, which do
you want?" and then only copy the requested directory/contents.

> Nah. Especially as we happen to have one, nay, two workarounds in place:
> * svn rm URL. Simply remove the offending empty directory from the
> repository, end of problem. This works from all platforms, since
> URLs are always case-sensitive.

This would leave a 2 year hole in the repository from the standpoint of NT and OSX.

> * svn dump | svndumpfilter | svn load. Remove the offending
> directory from _all_ revisions in the repository, or with a bit
> more work, just from the point in time when it was renamed. While
> this is more work than the previous solution, it does mean that you
> get consistent state in pre-HEAD revisions.

This, at least, only leaves a ~4 month hole in the repository. It's probably
what I will recommend for the perl.org repository, or rather to manufacture a
commit at the correct moment which will delete the directories.

What bugs me the most is that this is not a very nice way for the svn client to
act. It means that the repository is virtually inaccessible, but only from a
specific O/S; everywhere else it is fine. If I could check out the repos, with
warnings, rather than having it error out, that would be acceptable I think.


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 30 19:16:48 2003

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

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