[Gnu-arch-users] Re: Case insensitive file systems [was: tla1.2 on cygwin]

[Dustin Sallings]

On Mar 10, 2004, at 15:27, Tom Lord wrote:

> It doesn't solve the problem.   By coincidence, it works around one
> particular case of the problem you've encountered.   My 2003b archive
> would still trip you up, for example (LabNotes v. labnotes).

	Yes, labnotes was a confusing problem for me when I first tried to 
mirror 2003b, but I didn't need all of that stuff, so I just got the 
parts I wanted.

	We clearly disagree on the importance of having the structure in 
{arch} be consistent with the way archives are specified (i.e. having 
address@hidden/a--b--c--d logs live in 
{arch}/address@hidden/a/a--b/a--b--c/patch-logs/d).  The 
archive name is already globally unique and the most significant part.  
It seems to me that the category and branch names should be completely 
meaningless to anyone other than the archive owner.  What you're 
advocating (and, I believe, have been suggesting by having this 
structure) is that the category and branch names should be more 
significant to everyone than the name of the archive from which the 
patch originated.

	I think limiting category and branch names within an archive to where 
you couldn't end up with LabNotes and labnotes would be a good move 
(after all, are they really representing two different categories of 
stuff?).  However, I think it's a little much to limit branch names in 
private branches to some kind of convention just in case changes within 
that branch make it back into the upstream project and someone else 
wants to do a private dev branch with a similar name.

	But yeah, it is a side-effect of this design decision that is 
affecting me and I'm sure someone else can come up with something else 
that would affect me (someone merging in changes from two branches with 
names that are similar except for case in the same category in the same 
archive).

	So, I guess I have two problems.  One of them is more aesthetic and 
fairly difficult and one of them is a bit broader and may have other, 
more complete solutions.  It just so happens that solving the first one 
takes care of most of my worries (and real-world problems) here.

--
Dustin Sallings