John Peacock wrote:
> Branko Čibej wrote:
>
>> 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.
I'm not quite sure what you mean by a "hole". It certainly wouldn't help
with checkouts of revisions from before the deletion, yes.
> * 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.
Ah, I think I see -- you're saying there was a period of time when both
lib/unicode and lib/Unicode existed and were live. I'm sure this caused
problems with _any_ version control system on NT and OS/X, and the only
"solution" I can think of is to actually fiddle with the SVN repo dump
file to rename lib/unicode to lib/unicore at the point where lib/Unicode
was first created. This is a bit drastic, as it would mean that while
you can check out revisions from that period on NT, you can't build the
source anywhere any more.
> 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.
Heh, I'd turn this around and say it was not a very nice way for the
Perl repository admin to act when the directories with conflicting names
were created in the first place. It's not as if systems with
case-insensitive filenames were an obscure niche market. :-)
> 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.
The only marginally sensible way of handling this -- apart from imposing
a project-wide naming convention that prevents such conflicts -- would
be to add directory renaming capabilities to the SVN client. This would
be a tricky thing to design, as there are many edge cases and
interactions that have to be taken into account. But it's definitely
easier to get correct than the merging functionality you proposed.
However, I'd hesitate to propose this even as a post-1.0 feature until a
survey showed a lot more such cases in important open source
repositories than just a 4 month period in Perl's.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 31 07:47:34 2003