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

Re: SVN 1.5 - Beta 1 - mkdir behavior

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Tue, 18 Mar 2008 22:32:35 -0500

C. Michael Pilato wrote:
> Troy Curtis Jr wrote:
>> On Tue, Mar 18, 2008 at 12:38 PM, Karl Heinz Marbaise
>> <khmarbaise_at_gmx.de> wrote:
>>> Hi there,
>>>
>>> i have observed a little bit odd behavior (in my opinion) of the mkdir
>>> comment in relationship with the --parents option...
>>>
>>> I have created a clean new repository and after that i have given the
>>> following on the command line:
>>>
>>> svn mkdir --parents \
>>> $URL/project1/trunk \
>>> $URL/project1/tags \
>>> $URL/project1/branches \
>>> $URL/project2/trunk \
>>> $URL/project2/tags \
>>> $URL/project2/branches -m"- First structure"
>>>
>>> and got an error message:
>>> svn: File already exists: filesystem '...', transaction '0-0', path
>>> '/project1'
>>>
>>> Is this intended behavior ? Or is my understanding not correct...
>>> I had expected that those two intermediate directories (project1 and
>>> project2) would have been created and the structure in the
>>> repository as
>>> well....
>>>
>>> Can someone enlighten me...
>>> Thanks in advance...
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>> --
>>> SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
>>> Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029
>>> Hauptstrasse 177 USt.IdNr: DE191347579
>>> 52146 Würselen http://www.soebes.de
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
>>> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>>>
>>>
>>
>> I am not really a developer here, but this is an interesting issue. I
>> think you'll get an idea of what is going on if you allow it to open
>> an editor instead of providing a log message on the command-line. You
>> get the following:
>>
>> A $URL/project1
>> A $URL/project1/trunk
>> A $URL/project1
>> A $URL/project1/tags
>> A $URL/project1
>> A $URL/project1/branches
>> A $URL/project2
>> A $URL/project2/trunk
>> A $URL/project2
>> A $URL/project2/tags
>> A $URL/project2
>> A $URL/project2/branches
> >
>> So it seems that it is expanding the intermediate targets for each
>> argument
>> independently, not looking at any other targets being made. I would
>> certainly
>> say that this is unexpected behavior.
>
> That's a great clue, Troy!
>
>> Personally I think it would be worth a bug report, as it really does
>> not match what you would get from the Linux command-line 'mkdir -p'
>> command.
>
> Yes, this is definitely a bug. And the following is, I think, the fix:
>
> Index: subversion/libsvn_client/add.c
> ===================================================================
> --- subversion/libsvn_client/add.c (revision 29944)
> +++ subversion/libsvn_client/add.c (working copy)
> @@ -34,6 +34,8 @@
> #include "svn_io.h"
> #include "svn_config.h"
> #include "svn_props.h"
> +#include "svn_hash.h"
> +#include "svn_sorts.h"
> #include "client.h"
>
> #include "svn_private_config.h"
> @@ -636,6 +638,7 @@
> const char *log_msg;
> apr_hash_t *revprop_table;
> apr_array_header_t *targets;
> + apr_hash_t *targets_hash;
> svn_error_t *err;
> const char *common;
> int i;
> @@ -667,6 +670,8 @@
>
> /* Condense our list of mkdir targets. */
> SVN_ERR(svn_path_condense_targets(&common, &targets, urls, FALSE,
> pool));
> + SVN_ERR(svn_hash_from_cstring_keys(&targets_hash, targets, pool));
> + SVN_ERR(svn_hash_keys(&targets, targets_hash, pool));
>
> if (! targets->nelts)
> {
> @@ -702,6 +707,8 @@
> }
> }
> }
> + qsort(targets->elts, targets->nelts, targets->elt_size,
> + svn_sort_compare_paths);
>
> /* Create new commit items and add them to the array. */
> if (SVN_CLIENT__HAS_LOG_MSG_FUNC(ctx))
>

Nice use of hashes, Mike! I haven't tested it, but the patch looks good
to me.

-Hyrum

Received on 2008-03-19 04:32:52 CET

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

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