Actually it's really a matter of interpretation whether or not the
different case should represent a "conflict" or not. To be completely
flexible, you'd expect the platform dependent client to issue a warning
and a chance for the user to choose which interpretation (and possibly
local renaming to resolve the ambiguity).
The fact is that the Windows client may potentially not be able to
represent the repository when case sensitive filenames are used... which
is a good reason to be able to turn this "feature" off on the server
side.
Peter
-----Original Message-----
From: Peter Yamamoto [mailto:peter.yamamoto@page44.com]
Sent: Tuesday, December 21, 2004 2:22 PM
To: Gili; Norbert Unterberg; Peter N. Lundblad
Cc: users@subversion.tigris.org
Subject: RE: Re: Renaming files on win32
It's not just a unix vs win issue either... we had a similar problem in
a completely win environment where the application software supported
crossplatform clients and hence was case sensitive.
I can't recall the exact circumstances and tools, but we had case and
'duplicate' file/folder name issues when using StarTeam which is a
cross-platform version control package.
For example, one person would create/add a file in a folder (for example
a texture file generated at some point by some artist). Later another
artist may work on the file and whether through tools or simply because
of having to retype a name, use a different casing. Ultimately a file
with the same (intended) contents but different casing is on the drive.
According to the server (which supports mixed case) this file is
different than the file already in that folder and hence can be *added*.
Eg they never checked out the original version, and this "new" file
technically was different from the same file from the server's point of
view.
On the server side all is "fine" so to speak. But back on the client
side, the file would continuously be in "modified/conflict" since when
it got checked out, the software would say it's a different version than
the other named file [since at this point the local workspace
technically does have "both" versions being represented in the same
file!-P]. Of course the real problem should have been that it should
have shown up as in conflict in the first place before allowing the add.
I guess the point is that you have to be very careful about the
layers/operations where you try to shield windows clients from this
anomaly, while still trying to preserve the capabilities of the server
side representation of the repository.
Peter
-----Original Message-----
From: Gili [mailto:junk@bbs.darktech.org]
Sent: Tuesday, December 21, 2004 2:04 PM
To: Norbert Unterberg; Peter N. Lundblad
Cc: users@subversion.tigris.org
Subject: Re: Renaming files on win32
On Tue, 21 Dec 2004 22:57:42 +0100, Norbert Unterberg wrote:
>I even do not see the need to drop case-sensitivity in subversion
>(server part) to make the windows svn client behave as a windows user
>would expect (at least for the working copy). Since svn stores a copy
>of the file with the original file name in the text-base, the client
>can detect the original name (as stored in the repository) and identify
>the file, then take the action required to recognize the file, move,
>checkin, rename etc, even if the case of the name changed. This should
>be possible without server changes, shouldn't it?
>
>Norbert
>(not knwoing too much details about svn internals)
Yes, but I am concerned about what happens when someone checks
in different files "abc" and "Abc" with a Unix client and then someone
under win32 tries to check them out.
Gili
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 21 23:36:53 2004