RE: [PATCH] svn_load_dirs.pl: fails if one file/folder is replaced by a symb link, or a symb link is replaced by a file/folder

Log message:

   * contrib/client-side/svn_load_dirs/svn_load_dirs.pl.in
     (while main loop, digest_hash_file): Avoid to stop the execution with failure return, if source or dest is a symbolic link.
     (while main loop): Use the new function link_manager when necessary.
     (link_manager): New function to manage specificly the symbolic links in a remove/commit/update/add cycle when necessary.

Best regards.

Philippe.

-----Original Message-----
From: Hyrum K. Wright [mailto:hyrum_wright_at_mail.utexas.edu]
Sent: mardi 11 décembre 2007 00:04
To: Demange_2, Philippe
Cc: 'dev_at_subversion.tigris.org'
Subject: Re: [PATCH] svn_load_dirs.pl: fails if one file/folder is replaced by a symb link, or a symb link is replaced by a file/folder

Demange_2, Philippe wrote:
> Hi,
>
> I got big troubles trying to import an external delivery with svn_load_dirs.pl (this is in part related to bug 2655 reported by Marc Girod, but treats symb links specificly):
>
> In the first delivery, there is a lot of folders containing mostly the same code.
> In the following delivery, these folders become, greatfully, symbolic links targetting a common and unique folder.
> Then svn_load_dirs.pl behaves like in the following example:
>
> I import a folder 'foo' containg a file 'bar', whose content is "zoo" into the repository.
> Then I decide to rename the file 'bar' to 'zoo', because it's more convenient.
> But I want to keep the file 'bar' available for, let's say, compilation compatibility, so I create a symb link:
> 'ln -s zoo foo/bar'
>
> And now I want to import these modifs on the repository with svn_load_dirs.pl:
> (I rename 'foo' into 'new_foo', otherwise svn_load_dirs.pl complains)
> "
>> svn_load_dirs.pl http://repos/svn/project/branches foo new_foo
> Checking that the base URL is a Subversion repository.
> Running /usr/bin/svn log -r HEAD --non-interactive http://repos/svn/
> project /branches
>
> Finding the root URL of the Subversion repository.
> Running /usr/bin/svn log -r HEAD --non-interactive http://repos
> Running /usr/bin/svn log -r HEAD --non-interactive http://repos/svn
> Running /usr/bin/svn log -r HEAD --non-interactive
> http://repos/svn/project Determined that the svn root URL is http://repos/svn/ project.
>
> Native EOL on this system is \012.
>
> Finding if any directories need to be created in repository.
> Running /usr/bin/svn log -r HEAD --non-interactive http://repos/svn/
> project /branches/foo No directories need to be created to prepare repository.
> Checking out http://repos/svn/project/branches/foo into
> /tmp/svn_load_dirs_Xo1GRkuY0f/my_import_wc
> Running /usr/bin/svn checkout --non-interactive http://repos/svn/
> project /branches/foo my_import_wc
>
> Loading new_foo.
> /home/demange/tmp/svn_load_dirs.pl: does not handle changing source and destination type for 'bar'.
> Cleaning up /tmp/svn_load_dirs_Xo1GRkuY0f "
>
> The attached patch aims to allow this kind of operation. Everytime that a source file and dest file match in their name but dismatch in their types, it checks if one them is a symbolic link. If so, it:
> - runs 'svn rm' on the dest file
> - commit the rm operation
> - copies and runs 'svn add' on the source file
>
> As Marc Girod mentionned here:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2655
>
> , I also have difficulties to avoid a list of consecutive commit operations (which can be __very__ long).
> I would prefer to run the commit operation once, but I don't know the script well enough to do so.

Thanks for the patch. Could you please provide a log message for this patch, using our log message guidelines (http://subversion.tigris.org/hacking.html#log-messages)? A good log message helps potential reviewers understand the changes in your patch, and increases the likelihood that it will be applied.

Thanks,
-Hyrum

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org