You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Rafael Garcia-Suarez <ra...@hexaflux.com> on 2002/10/25 10:31:41 UTC
Minor annoyance in svn add
$ mkdir -p foo/bar
$ svn add foo/bar foo
svn: No such file or directory
svn: svn_io_file_open: can't open `foo/.svn/lock'
The order of arguments to svn add is important.
This is a minor annoyance, but I can harm programs
that generate and perform svn commands automatically,
and sometimes svn add -R is not an option.
The obvious kludgy hack to solve this partially
is to sort the targets to svn add by length. (I propose
this hack, but I don't like it.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Minor annoyance in svn add
Posted by Philip Martin <ph...@codematters.co.uk>.
"Kirby C. Bohling" <kb...@birddog.com> writes:
> > I think the general solution is to call svn_path_get_absolute and then
> > sort using svn_path_is_child. A bit like svn_path_condense_targets.
>
> Just an idea. Add the equivilent of mkdir -p,--parents, which means if
> there is a component of this path which you must add first, add it, then
> add the subcomponent all the way down.
It's been suggested that svn mkdir should have such an option. It's
probably not correct to do it by default, either for mkdir or add,
since if you mistype a name you should probably get an error. If you
have to specify an option to get the behaviour then it doesn't solve
the problem that 'svn add foo/bar foo' fails; I'm happy leaving add
as it is and saying the failure is due to user error.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Minor annoyance in svn add
Posted by "Kirby C. Bohling" <kb...@birddog.com>.
On Fri, 2002-10-25 at 13:43, Kirby C. Bohling wrote:
> On Fri, 2002-10-25 at 13:36, Philip Martin wrote:
> >
> > It's not a simple problem however you do it. Consider
> >
> > $ cd /xxx/xxx
> > $ mkdir aaa
> > $ mkdir aaa/aaa
> > $ svn add aaa/aaa /xxx/xxx/aaa
> >
> > where we need /xxx/xxx/aaa before aaa/aaa, versus
> >
> > $ cd /aaa
> > $ mkdir xxx
> > $ mkdir xxx/xxx
> > $ svn add /aaa/xxx/xxx xxx
> >
> > where we need xxx before /aaa/xxx/xxx
> >
> > I think the general solution is to call svn_path_get_absolute and then
> > sort using svn_path_is_child. A bit like svn_path_condense_targets.
>
> Just an idea. Add the equivilent of mkdir -p,--parents, which means if
> there is a component of this path which you must add first, add it, then
> add the subcomponent all the way down. Maybe --add-parents instead of
> --parents. If svn prints an error for adding something that is already
> added that might be an issue, but possibly supressing it when --parents
> would work. I always use this when I'm scripting up the creation of a
> path, because it's easier then ensuring the entire path exists. I
> suppose it might be slower then the other way. However, your solving
> the problem more directly which appeals to me.
>
> Kirby
Darn it, should think longer before clicking send. --parents would do
bad things in the absolute path case. It didn't occur to me, because
CVS won't let me add stuff using a relative path from above the working
copy. ie:
cvs add dir_above/wc/sub_dir/file.c
doesn't work.
cd dir_above/wc ; cvs add sub_dir/file.c does work.
Sorry about the noise,
Kirby
>
>
> >
> > --
> > Philip Martin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
> --
> Real Programmers view electronic multimedia files with a hex editor.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
Real Programmers view electronic multimedia files with a hex editor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Minor annoyance in svn add
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 25 October 2002 11:43, Kirby C. Bohling wrote:
> Just an idea. Add the equivilent of mkdir -p,--parents, which means if
> there is a component of this path which you must add first, add it, then
> add the subcomponent all the way down.
Yet another use case for --parents :)
So far there's svn mkdir, add, import, cp, mv.
> Maybe --add-parents instead of --parents.
There are lots of other commands that could potentially use --parents, so it
should be consistant.
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9uZZIhDAgUT1yirARApndAKCMXRoMCwd8NB20dvdIgzWxMK6B7gCeNptE
FUsbXKj4FudX3ML1GxfDxk0=
=UleU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Minor annoyance in svn add
Posted by Noel Yap <ya...@yahoo.com>.
--- "Kirby C. Bohling" <kb...@birddog.com> wrote:
> Just an idea. Add the equivilent of mkdir
> -p,--parents, which means if
> there is a component of this path which you must add
> first, add it, then
> add the subcomponent all the way down. Maybe
> --add-parents instead of
> --parents. If svn prints an error for adding
> something that is already
> added that might be an issue, but possibly
> supressing it when --parents
> would work. I always use this when I'm scripting up
> the creation of a
> path, because it's easier then ensuring the entire
> path exists. I
> suppose it might be slower then the other way.
> However, your solving
> the problem more directly which appeals to me.
I like this "think outside of the box" suggestion --
get rid of the problem altogether (I prefer --parents
over --add-parents, BTW). OTOH, I would also like a
belt-and-suspenders approach in which "svn add" should
work as expected regardless of the order of the
arguments.
Noel
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Minor annoyance in svn add
Posted by "Kirby C. Bohling" <kb...@birddog.com>.
On Fri, 2002-10-25 at 13:36, Philip Martin wrote:
> Noel Yap <ya...@yahoo.com> writes:
>
> > --- Philip Martin <ph...@codematters.co.uk> wrote:
> > > Rafael Garcia-Suarez
> > > <ra...@hexaflux.com> writes:
> > >
> > > > What do you mean, "number of components" ?
> > > ./././///./foo is still longer that foo/bar.
> > >
> > > Use svn_path_decompose and don't count
> > > SVN_EMPTY_PATH components.
> >
> > Whenever I've needed to do this in the past, I used
> > sort to "alphabetize" the list. I think it should
> > work since "foo" comes before "foo/bar" in such a
> > sort. Assuming svn_path_decompose gets rid of "./"
> > and "//", using it before sorting should do what's
> > needed.
>
> It's not a simple problem however you do it. Consider
>
> $ cd /xxx/xxx
> $ mkdir aaa
> $ mkdir aaa/aaa
> $ svn add aaa/aaa /xxx/xxx/aaa
>
> where we need /xxx/xxx/aaa before aaa/aaa, versus
>
> $ cd /aaa
> $ mkdir xxx
> $ mkdir xxx/xxx
> $ svn add /aaa/xxx/xxx xxx
>
> where we need xxx before /aaa/xxx/xxx
>
> I think the general solution is to call svn_path_get_absolute and then
> sort using svn_path_is_child. A bit like svn_path_condense_targets.
Just an idea. Add the equivilent of mkdir -p,--parents, which means if
there is a component of this path which you must add first, add it, then
add the subcomponent all the way down. Maybe --add-parents instead of
--parents. If svn prints an error for adding something that is already
added that might be an issue, but possibly supressing it when --parents
would work. I always use this when I'm scripting up the creation of a
path, because it's easier then ensuring the entire path exists. I
suppose it might be slower then the other way. However, your solving
the problem more directly which appeals to me.
Kirby
>
> --
> Philip Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
Real Programmers view electronic multimedia files with a hex editor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Minor annoyance in svn add
Posted by Noel Yap <ya...@yahoo.com>.
--- Philip Martin <ph...@codematters.co.uk> wrote:
> Noel Yap <ya...@yahoo.com> writes:
> > Whenever I've needed to do this in the past, I
> used
> > sort to "alphabetize" the list. I think it should
> > work since "foo" comes before "foo/bar" in such a
> > sort. Assuming svn_path_decompose gets rid of
> "./"
> > and "//", using it before sorting should do what's
> > needed.
>
> It's not a simple problem however you do it.
> Consider
>
> $ cd /xxx/xxx
> $ mkdir aaa
> $ mkdir aaa/aaa
> $ svn add aaa/aaa /xxx/xxx/aaa
>
> where we need /xxx/xxx/aaa before aaa/aaa, versus
>
> $ cd /aaa
> $ mkdir xxx
> $ mkdir xxx/xxx
> $ svn add /aaa/xxx/xxx xxx
>
> where we need xxx before /aaa/xxx/xxx
>
> I think the general solution is to call
> svn_path_get_absolute and then
> sort using svn_path_is_child. A bit like
> svn_path_condense_targets.
In the above cases, sorting should still work since
ASCII '/' comes before ASCII 'a'. OTOH, you do bring
up a very good point since my suggestion won't work
when directory names begin with characters whose ASCII
code is less than that of '/' (eg '+').
Simple sorting may still work if paths starting with
'/' were special-cased.
I'm not familiar with the svn_ functions and I'm not
implementing the patch to fix this, anyway, so I'll
stop rambling. Thanks for pointing out holes in my
suggestion.
Noel
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Minor annoyance in svn add
Posted by Philip Martin <ph...@codematters.co.uk>.
Noel Yap <ya...@yahoo.com> writes:
> --- Philip Martin <ph...@codematters.co.uk> wrote:
> > Rafael Garcia-Suarez
> > <ra...@hexaflux.com> writes:
> >
> > > What do you mean, "number of components" ?
> > ./././///./foo is still longer that foo/bar.
> >
> > Use svn_path_decompose and don't count
> > SVN_EMPTY_PATH components.
>
> Whenever I've needed to do this in the past, I used
> sort to "alphabetize" the list. I think it should
> work since "foo" comes before "foo/bar" in such a
> sort. Assuming svn_path_decompose gets rid of "./"
> and "//", using it before sorting should do what's
> needed.
It's not a simple problem however you do it. Consider
$ cd /xxx/xxx
$ mkdir aaa
$ mkdir aaa/aaa
$ svn add aaa/aaa /xxx/xxx/aaa
where we need /xxx/xxx/aaa before aaa/aaa, versus
$ cd /aaa
$ mkdir xxx
$ mkdir xxx/xxx
$ svn add /aaa/xxx/xxx xxx
where we need xxx before /aaa/xxx/xxx
I think the general solution is to call svn_path_get_absolute and then
sort using svn_path_is_child. A bit like svn_path_condense_targets.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Minor annoyance in svn add
Posted by Noel Yap <ya...@yahoo.com>.
--- Philip Martin <ph...@codematters.co.uk> wrote:
> Rafael Garcia-Suarez
> <ra...@hexaflux.com> writes:
>
> > What do you mean, "number of components" ?
> ./././///./foo is still longer that foo/bar.
>
> Use svn_path_decompose and don't count
> SVN_EMPTY_PATH components.
Whenever I've needed to do this in the past, I used
sort to "alphabetize" the list. I think it should
work since "foo" comes before "foo/bar" in such a
sort. Assuming svn_path_decompose gets rid of "./"
and "//", using it before sorting should do what's
needed.
Noel
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Minor annoyance in svn add
Posted by Philip Martin <ph...@codematters.co.uk>.
Rafael Garcia-Suarez <ra...@hexaflux.com> writes:
> What do you mean, "number of components" ? ./././///./foo is still longer that foo/bar.
Use svn_path_decompose and don't count SVN_EMPTY_PATH components.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Minor annoyance in svn add
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Rafael Garcia-Suarez <ra...@hexaflux.com> writes:
> What do you mean, "number of components" ? ./././///./foo is still
> longer that foo/bar.
Number of, uh, "real components", I meant... Ummm... Yeah.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Minor annoyance in svn add
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Karl Fogel <kf...@newton.ch.collab.net> wrote:
> > The order of arguments to svn add is important.
> > This is a minor annoyance, but I can harm programs
> > that generate and perform svn commands automatically,
> > and sometimes svn add -R is not an option.
> >
> > The obvious kludgy hack to solve this partially
> > is to sort the targets to svn add by length. (I propose
> > this hack, but I don't like it.)
>
> Where length is measured by number of components, yeah... Might work.
What do you mean, "number of components" ? ./././///./foo is still longer that foo/bar.
> Rafael, can you file an issue for this? Thanks.
I'll do this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Minor annoyance in svn add
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Rafael Garcia-Suarez <ra...@hexaflux.com> writes:
> $ mkdir -p foo/bar
> $ svn add foo/bar foo
> svn: No such file or directory
> svn: svn_io_file_open: can't open `foo/.svn/lock'
>
> The order of arguments to svn add is important.
> This is a minor annoyance, but I can harm programs
> that generate and perform svn commands automatically,
> and sometimes svn add -R is not an option.
>
> The obvious kludgy hack to solve this partially
> is to sort the targets to svn add by length. (I propose
> this hack, but I don't like it.)
Where length is measured by number of components, yeah... Might work.
Rafael, can you file an issue for this? Thanks.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org