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

RE: svn_load_dirs case-insensitive comparisons on Windows

From: Jeremiah van Oosten <jvoosten_at_playlogicgames.com>
Date: Thu, 21 Aug 2008 09:34:00 +0200

Thanks Ryan for your reply,

Unfortunanlty, there are many different people working on these assets
that are being exported and it might be the fault of the particular user
who is doing the export that they are not using the exact same case when
they modify and re-export the assets (it might even be the case that
they are exporting on different OS's and on Unix breeds perhaps the
exports are always in lowercase?), however it isn't the 3rd party
software that is failing during export so there is no perceivable error
there. In addition, the 3rd party asset creation team is not using SVN
and thus may never realize what is at fault.
 
The failure occurs when trying to import the content into a vendor
branch using the svn_load_dirs.pl script. Since it is the script that is
failing, it is the script that should be adapted to account for this
occurance.

Regards,

Jeremiah

-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2008c_at_ryandesign.com]
Sent: August 20, 2008 9:45 PM
To: Jeremiah van Oosten
Cc: Subversion Users
Subject: Re: svn_load_dirs case-insensitive comparisons on Windows

On Aug 20, 2008, at 12:58, Blair Zajac wrote:

> Jeremiah van Oosten wrote:
>
>> We are currently using svn_load_dirs to import asset drops from a
>> 3rd part asset creation team.
>> It occurs quite often that files (literally thousands of files)
>> sent from the asset creation team have changed their names only by
>> case and not by name.
>> For example, the file "Image_Asset_01" in drop 1 has changed to
>> "image_asset_01" in the next drop (notice only the case of the
>> letters has changed between the two file names).
>> When we use svn_load_dirs to update the vendor branch, the script
>> will think that the file "Image_Asset_01" is deleted, and
>> "image_asset_01" is added to the vendor branch.
>> However, on Windows, when the file "image_asset_01" is copied from
>> the source drop folder to the working copy location, the file
>> "Image_Asset_01" file is replaced and the file name remains
>> "Image_Asset_01" (on Windows, file names are not considered case-
>> sensitive!).
>> Later, svn_load_dirs tries to perform a "svn delete" on the file,
>> but the file has local modifications (because of the copy) and the
>> "svn delete" command fails, causing the script to fail. Well, of
>> course we don't want the delete operation to succeed, because the
>> file should be updated in the repository.
>> What I would like to have is an optional argument (or automatic
>> defaults depending on the OS) that allows svn_load_dirs to create
>> its "add" and "delete" lists based on a case-insensitive file-name
>> matching. Hopefully this would prevent the svn_load_dirs script
>> from trying to add or delete files that should only be updated.
>> I looked into the script myself, but I'm not very proficient in
>> Perl and couldn't really pin-point the part of the script that is
>> building the add and delete lists :)
>> Does anybody have a solution to this? Better yet, perhaps the
>> script can be updated to include this option (default to case-
>> insensitive file-name matching on Windows) and available in the
>> next update? (Perhaps I need to submit an issue to the issue
>> tracker?)
>
> I wrote svn_load_dirs.pl and there's no active development on it.
>
> An easier solution would be to rename all the files you get from
> the 3rd party asset creation team into all lowercase and then use
> svn_load_dirs.pl. You would probably want to 'svn mv' all the
> existing files in svn into their lowercase variant and then use
> svn_load_dirs.pl.

I would consider it a user error to be randomly changing the case of
filenames. Users shouldn't do that.

Of course, it may be a 3rd-party tool that's changing the filename
case for the users. In that case, it is a bug in the 3rd-party tool.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-23 01:08:11 CEST

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

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