You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Demange_2, Philippe" <ph...@philips.com> on 2007/10/12 10:16:12 UTC

[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

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.


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

Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Issue #3088.

Demange_2, Philippe wrote:
> 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@mail.utexas.edu]
> Sent: mardi 11 décembre 2007 00:04
> To: Demange_2, Philippe
> Cc: 'dev@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.


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

Posted by "Demange_2, Philippe" <ph...@philips.com>.
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@mail.utexas.edu]
Sent: mardi 11 décembre 2007 00:04
To: Demange_2, Philippe
Cc: 'dev@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


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

Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
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