You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Peter Davis <pe...@pdavis.cx> on 2002/10/16 09:31:36 UTC
Making import syntax consistant with mv, cp, export
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> I would expect this to import ./graphics/bsp into the repository root,
> -> file://path/to/repos/bsp/readme.txt
>
> I think my expectation is due to cp, mv, rsync, etc. which AFAIK all
> work on the named directory if the target is an existing directory and
> I think about the repos path as a directory.
Hmm, I hadn't thought of it like that. Yes, cp, mv, etc. do treat the last
path element as the target, even if that element is a directory.
That makes me think, should import work more like cp and mv? Right now I
can't even really summarize how to think of import, even with the new syntax
proposal; something like, "take this URL and copy all of the files under the
source into it". Should we think of it more simply as "copy this local
directory into the repository"? In that case, it should really be:
$ svn import SOURCE REPOS-URL/[NEW-ENTRY]
SOURCE could actually be multiple arguments, so
$ svn import ./graphics/bsp/* REPOS-URL
work work essentially the same as
$ cd ./graphics/bsp
$ svn import . REPOS-URL
If you type the following:
$ svn import ./graphics/bsp REPOS-URL
then you will actually end up with a new directory "bsp/" under REPOS-URL,
since bsp/ and its contents are the target of the operation. This is as
opposed to the way import works now and the way it would work under my last
proposal, where the "bsp/" directory would *not* be created under REPOS-URL;
only its contents would be copied.
This would make it work exactly the same as "svn copy", only it works with
non-versioned files/directories. In fact, maybe import should be revamped to
support files as arguments as well.
This would make cp/import a nice complement to checkout/export. With export,
it's just reversed: "Copy the contents of this URL into this local
directory". Export's arguments represent that thought: "svn export
REPOS-URL/PATH LOCAL-DESTINATION".
So, what does everyone else think of this? Now that Benjamin has pointed it
out, this new style actually makes more sense to me.
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9rTH7hDAgUT1yirARAq7ZAKCJOstvraeYqJzwMlSaZpZNoEoHRQCeNlay
TWpZe8oicLYy//tks4TDBgk=
=kjVf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making import syntax consistant with mv, cp, export
Posted by mark benedetto king <bk...@inquira.com>.
On Wed, Oct 16, 2002 at 02:31:36AM -0700, Peter Davis wrote:
> This would make it work exactly the same as "svn copy", only it works with
> non-versioned files/directories. In fact, maybe import should be revamped to
> support files as arguments as well.
>
What if we were to toss import/export and just make them special cases
of copy (non-URL non-wc-path parameters).
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making import syntax consistant with mv, cp, export
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Remembering to include "graphics/" but not "bsp/" in the URL is the only
problem I see with this.
Maybe import should not automatically create parent directories?
Maybe this is another possible use for a global "-p" or "--create-parents"
option, which would apply both to mkdir and to import in this case, and could
be extended to cp and mv as well. I believe that option was rejected because
it was only used by mkdir.
On Wednesday 16 October 2002 09:33, Brent Burton wrote:
> In past messages we discussed making new parent/extra directories in the
> repository with 'svn import' by simply naming them in the repository path.
>
> I.e., if an empty repository dir looks like:
> $URL/repos/
> and we run 'svn import graphics/bsp $URL/repos' then we get:
> $URL/repos/bsp
>
> If we want to preserve the graphics directory, would we then
> specify 'svn import graphics/bsp $URL/repos/graphics' to get:
> /repos/graphics/bsp ,
> or just rely on 'svn mkdir'. How much congruency is desired between 'svn
> import' and cp(1), mv(1), etc, will dictate whether this naming shortcut
> is warranted.
>
> Is this shortcut something you want to worry with right now?
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9rbWjhDAgUT1yirARAkZ4AJ9c48vQumYsaziKaXUZyioe9OtYsgCfYdgi
GrXUWR3AI9xVNyDGiAtc6RE=
=mvNY
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making import syntax consistant with mv, cp, export
Posted by Brent Burton <br...@io.com>.
On Wed, 16 Oct 2002, Peter Davis wrote:
> [...]
> Hmm, I hadn't thought of it like that. Yes, cp, mv, etc. do treat the last
> path element as the target, even if that element is a directory.
That's right, we overlooked that (or, at least I know I did in my
past message).
> That makes me think, should import work more like cp and mv? Right now I
> can't even really summarize how to think of import, even with the new syntax
> proposal; something like, "take this URL and copy all of the files under the
> source into it". Should we think of it more simply as "copy this local
> directory into the repository"?
I believe so. Making the usage similar to well-known tools
isn't a liability. Let's think about 'cp -r target [target ...] dest'.
That really is what the import statement is doing, is essentially
copying a nonversioned source hierarchy into the repository.
> In that case, it should really be:
> $ svn import SOURCE REPOS-URL/[NEW-ENTRY]
> SOURCE could actually be multiple arguments, so
> $ svn import ./graphics/bsp/* REPOS-URL
>
> work work essentially the same as
> $ cd ./graphics/bsp
> $ svn import . REPOS-URL
>
> If you type the following:
> $ svn import ./graphics/bsp REPOS-URL
> then you will actually end up with a new directory "bsp/" under REPOS-URL,
> since bsp/ and its contents are the target of the operation.
> So, what does everyone else think of this? Now that Benjamin has
> pointed it out, this new style actually makes more sense to me.
The new proposed usage above really nails it I think. One has
target files and directories they want tracked by SVN, and so
they import those targets into the repository. Stating "the obvious"
just makes clear the thinking, and the syntax.
On a related note...
In past messages we discussed making new parent/extra directories in the
repository with 'svn import' by simply naming them in the repository path.
I.e., if an empty repository dir looks like:
$URL/repos/
and we run 'svn import graphics/bsp $URL/repos' then we get:
$URL/repos/bsp
If we want to preserve the graphics directory, would we then
specify 'svn import graphics/bsp $URL/repos/graphics' to get:
/repos/graphics/bsp ,
or just rely on 'svn mkdir'. How much congruency is desired between 'svn
import' and cp(1), mv(1), etc, will dictate whether this naming shortcut
is warranted.
Is this shortcut something you want to worry with right now?
-Brent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org