You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Berlin <db...@dberlin.org> on 2005/10/17 00:30:03 UTC
Export behaving badly
So i'm converting over some documentation update scripts from gcc.
They do the following:
Export a bunch of doc files from repo
build docs
place them somewhere
export, unfortunately, behaves differently than checkout. If you do
svn export svn://gcc.gnu.org/svn/trunk/gcc/doc/install.texi gcc
It creates a file named "gcc" in the current directory, containing the
contents of install.texi
Fair enough, though different than checkout, which if you could checkout
a single file, presumably would have put it in gcc
So i create a dir named gcc
-bash-3.00$ mkdir gcc
-bash-3.00$ svn export file:///svn/gcc/trunk/gcc/doc/install.texi gcc
svn: Can't move 'gcc.2.tmp' to 'gcc': Is a directory
I *know* it's a directory.
That's why i gave it to you. To put the file in.
IMHO, export's extra argument should behave exactly like the one to
checkout, and effectively copy the file into that path.
The current behavior is just not sensible.
We had a discussion about whether to create the empty paths that are in
the URL or not (like CVS), and the consensus seemed to be no
But nobody disagreed that what happens now doesn't match the checkout
behavior, and probably should.
Anybody disagree?
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Export behaving badly
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-10-18 13:55:07 -0400, Greg Hudson wrote:
> Incidentally, earlier you said that the "export as copy" mental model is
> pointless for files because users can "svn cat file-url > file". (Does
> that mean that cp is pointless for files?) I'll note that such an
> approach does not obey the svn:executable property.
Yes, and not only that: "svn export" has a --native-eol option,
but not "svn cat". Also, "svn export" preserves the timestamp,
but not "svn cat ... > file". They also behave differently when
the file is a symbolic link.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Export behaving badly
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-10-17 at 22:32 -0400, Daniel Berlin wrote:
> > So you plan on arguing to make checkout consistent with your model when
> > we get around to implementing single file checkout?
>
> I ask this, btw, because the current mantra i hear is "export is
> checkout without producing the .svn dirs"
>
> If this is what we are going to tell people, we should prepared to stick
> with it (IE decide what both are going to do with single files in some
> consistent way), or stop saying it.
I honestly don't know.
I observe that my model is already what we've implemented (though
apparently we haven't documented it), so changing to your model has
compatibility issues.
One possibility is that we might never support checking out a single
file because we can't support it quite right. Or at least, not until
such a day as we have a second working copy model which doesn't use a
hidden-metadata-directory approach. A possible workaround for users
wanting to check out a single file is "svn co --depth=0 dir-url; cd dir;
svn up file", which generalizes to checking out two or three specific
files as well. (This is assuming a future where we have proper --depth
support and better non-recursive checkout handling.)
Incidentally, earlier you said that the "export as copy" mental model is
pointless for files because users can "svn cat file-url > file". (Does
that mean that cp is pointless for files?) I'll note that such an
approach does not obey the svn:executable property.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Export behaving badly
Posted by Daniel Berlin <db...@dberlin.org>.
> So you plan on arguing to make checkout consistent with your model when
> we get around to implementing single file checkout?
I ask this, btw, because the current mantra i hear is "export is
checkout without producing the .svn dirs"
If this is what we are going to tell people, we should prepared to stick
with it (IE decide what both are going to do with single files in some
consistent way), or stop saying it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Export behaving badly
Posted by Daniel Berlin <db...@dberlin.org>.
On Mon, 2005-10-17 at 18:12 -0400, Greg Hudson wrote:
> On Mon, 2005-10-17 at 08:13 -0400, Daniel Berlin wrote:
> > > You seem to be going from "checking out a
> > > directory would put the directory contents into the specified directory"
> > > to "exporting a file should put the file into the specified directory".
>
> > Well, yes.
> > And what exactly is wrong with that?
> > Why do you think the case for a single file should be different than the
> > case for a directory when it comes to where we place them?
>
> Do you understand that "cp -r dir1 dir2" and "cp file dir2" are not
> parallel use cases? The second is shorthand for "cp file dir2/file".
Of course i understand that.
>
> In one case, the second argument *is* the target path; in the other
> case, the second argument is the *container* for the target path.
>
> > Do you honestly believe a user expects the cases to behave differently?
> > As a user, it certainly surprised the heck out of me.
>
> Neither one of us can claim to be a user in the sense which is relevant
> to your argument here; we are both developers with lots of systems
> programming knowledge. Your expectations appear to be biased from
> having used cvs in a particular way.
Actually, i've spoken to quite a few users about this issue, as i
mentioned. Though admittedly, they've all used CVS. It's probably hard
to find a ton of now-subversion users who don't use windows who haven't
used CVS.
>
> >From what I can tell, in your mental model, exporting a file is
> shorthand for exporting its containing directory but leaving out all the
> other files.
Not quite. I just expect that if i've given it a directory, that it
puts it there, instead of complaining that i've given it a directory.
I would also, BTW, be perfectly satisfied if there was some real way to
tell export where to put things without me having to make the entire
directory structure and copy 3/4ths of the url, continuously.
IE svn export --to-dir=<where> <url>
and have it make "where" (if necessary) and plop the file down there.
> In my model, exporting a single file is like copying the
> file to a designated target path, just like exporting a directory is
> like copying that directory to a designated target path.
As Branko said, we have cat for that. So if that's the real model, IMHO
we should probably just disable export of a single file.
>
> I think it's important to do things for the right reasons.
>
So you plan on arguing to make checkout consistent with your model when
we get around to implementing single file checkout?
>
> You can take that as "I like to argue" if you're locked into those two
> particular options.
>
Bah. I was sick and frustrated by this behavior, sorry.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Export behaving badly
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-10-17 at 08:13 -0400, Daniel Berlin wrote:
> > You seem to be going from "checking out a
> > directory would put the directory contents into the specified directory"
> > to "exporting a file should put the file into the specified directory".
> Well, yes.
> And what exactly is wrong with that?
> Why do you think the case for a single file should be different than the
> case for a directory when it comes to where we place them?
Do you understand that "cp -r dir1 dir2" and "cp file dir2" are not
parallel use cases? The second is shorthand for "cp file dir2/file".
In one case, the second argument *is* the target path; in the other
case, the second argument is the *container* for the target path.
> Do you honestly believe a user expects the cases to behave differently?
> As a user, it certainly surprised the heck out of me.
Neither one of us can claim to be a user in the sense which is relevant
to your argument here; we are both developers with lots of systems
programming knowledge. Your expectations appear to be biased from
having used cvs in a particular way.
From what I can tell, in your mental model, exporting a file is
shorthand for exporting its containing directory but leaving out all the
other files. In my model, exporting a single file is like copying the
file to a designated target path, just like exporting a directory is
like copying that directory to a designated target path.
> IMHO, we are.
> I can't actually tell if you are arguing because you want to argue, or
> because you actually like the current behavior.
I think it's important to do things for the right reasons. Doing the
right thing for the wrong reasons can lead to making ancillary changes
which aren't right at all. If we buy your argument for changing the
behavior of "svn export file foo" when foo is an existing directory, we
might also change the behavior of "svn export file foo" when foo does
not exist, so that it creates a directory named foo and puts the file
into foo/file. I think that might be a mistake, because it would
violate the expectations of users who think of export as being like
copy. (Although I grant there is an argument from consistency with
hypothetical future "svn co file" functionality.)
You can take that as "I like to argue" if you're locked into those two
particular options.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Export behaving badly
Posted by Daniel Berlin <db...@dberlin.org>.
On Mon, 2005-10-17 at 03:52 -0400, Greg Hudson wrote:
> On Sun, 2005-10-16 at 20:30 -0400, Daniel Berlin wrote:
> > svn export svn://gcc.gnu.org/svn/trunk/gcc/doc/install.texi gcc
> >
> > It creates a file named "gcc" in the current directory, containing the
> > contents of install.texi
>
> Seems reasonable: take this file and put it there.
>
> > -bash-3.00$ mkdir gcc
> > -bash-3.00$ svn export file:///svn/gcc/trunk/gcc/doc/install.texi gcc
> > svn: Can't move 'gcc.2.tmp' to 'gcc': Is a directory
> >
> > I *know* it's a directory.
> > That's why i gave it to you. To put the file in.
> >
> > IMHO, export's extra argument should behave exactly like the one to
> > checkout, and effectively copy the file into that path.
>
> Arguing from consistency with checkout is weird, since you can't check
> out an indidivual file. You seem to be going from "checking out a
> directory would put the directory contents into the specified directory"
> to "exporting a file should put the file into the specified directory".
Well, yes.
And what exactly is wrong with that?
Why do you think the case for a single file should be different than the
case for a directory when it comes to where we place them?
Do you honestly believe a user expects the cases to behave differently?
As a user, it certainly surprised the heck out of me.
I'd argue from docs, but you'll note that export's docs doesn't talk
about exporting single files at all.
It does say
1. Exports a clean directory tree from the repository specified by
URL, at revision REV if it is given, otherwise at HEAD, into
PATH. If PATH is omitted, the last component of the URL is used
for the local directory name.
"into PATH"
not
"as PATH"
I would expect the single file case to put it *into* PATH if PATH is a
directory, and into PATH as a file otherwise.
>
> What you're really arguing from, I think, is cp, which special-cases "cp
> file dir" for convenience, treating dir/file as the target path rather
> than dir itself. I agree that we should probably do the same thing, but
> we're hardly being unreasonable or inconsistent.
IMHO, we are.
I can't actually tell if you are arguing because you want to argue, or
because you actually like the current behavior.
If the latter, i'd actually argue that it surprises all users who have
come across it, or at least all from CVS. Having talked with other
people who have converted from CVS to SVN, all those who had automated
scripts that did exports discovered this issue, and worked around it by
*checking out the entire copy of the tree instead of single files*, just
so they could get it to do what they want.
> "svn cat
> file://.../install.texi > gcc" would fail similarly, because the shell
> has no special case like cp does.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Export behaving badly
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2005-10-16 at 20:30 -0400, Daniel Berlin wrote:
> svn export svn://gcc.gnu.org/svn/trunk/gcc/doc/install.texi gcc
>
> It creates a file named "gcc" in the current directory, containing the
> contents of install.texi
Seems reasonable: take this file and put it there.
> Fair enough, though different than checkout, which if you could checkout
> a single file, presumably would have put it in gcc
Sure, but only because working copies must have a directory to put .svn
into. If we stored working copy metadata in homedirs, we might check
out individual files as just files.
(All kind of moot; you can't check out individual files at all yet.)
> -bash-3.00$ mkdir gcc
> -bash-3.00$ svn export file:///svn/gcc/trunk/gcc/doc/install.texi gcc
> svn: Can't move 'gcc.2.tmp' to 'gcc': Is a directory
>
> I *know* it's a directory.
> That's why i gave it to you. To put the file in.
>
> IMHO, export's extra argument should behave exactly like the one to
> checkout, and effectively copy the file into that path.
Arguing from consistency with checkout is weird, since you can't check
out an indidivual file. You seem to be going from "checking out a
directory would put the directory contents into the specified directory"
to "exporting a file should put the file into the specified directory".
What you're really arguing from, I think, is cp, which special-cases "cp
file dir" for convenience, treating dir/file as the target path rather
than dir itself. I agree that we should probably do the same thing, but
we're hardly being unreasonable or inconsistent. "svn cat
file://.../install.texi > gcc" would fail similarly, because the shell
has no special case like cp does.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Export behaving badly
Posted by Daniel Berlin <db...@dberlin.org>.
> >
> Oh come on. :)
Yeah, i'll admit it, i was lawyering you :)
>
> I'm merely suggesting that the solution to "export a single file" should
> be the same as the solution to "checkout a single file".
I don't disagree, it just bothers me to remove functionality users may
be using (though i guess i've already argued they don't like it :P).
>
> In other words, if someone takes the time to teach export to create a
> directory and put a single file in it, then we might as well do
> something similar for checkout (fixing co -N first, of course). Until
> then, I'd rather have export behave like checkout; if for no other
> reason than it's easier to explain export as "checkout without creating
> the .svn directories".
Yeah yeah.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Export behaving badly
Posted by Daniel Berlin <db...@dberlin.org>.
> >
> Oh come on. :)
Yeah, i'll admit it, i was lawyering you :)
>
> I'm merely suggesting that the solution to "export a single file" should
> be the same as the solution to "checkout a single file".
I don't disagree, it just bothers me to remove functionality users may
be using (though i guess i've already argued they don't like it :P).
>
> In other words, if someone takes the time to teach export to create a
> directory and put a single file in it, then we might as well do
> something similar for checkout (fixing co -N first, of course). Until
> then, I'd rather have export behave like checkout; if for no other
> reason than it's easier to explain export as "checkout without creating
> the .svn directories".
Yeah yeah.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Export behaving badly
Posted by Branko Čibej <br...@xbc.nu>.
Daniel Berlin wrote:
>On Mon, 2005-10-17 at 15:46 +0200, Branko Čibej wrote:
>
>
>>Daniel Berlin wrote:
>>
>>
>>
>>>So i'm converting over some documentation update scripts from gcc.
>>>
>>>They do the following:
>>>
>>>Export a bunch of doc files from repo
>>>build docs
>>>place them somewhere
>>>
>>>export, unfortunately, behaves differently than checkout. If you do
>>>
>>>svn export svn://gcc.gnu.org/svn/trunk/gcc/doc/install.texi gcc
>>>
>>>
>>>
>>>
>>I think export should simply fail for a single file, just like checkout.
>>
>>
>
>Checkout fails because it can't currently maintain a working copy
>alongside the single file
>
>Export doesn't fail because it doesn't need such a working copy.
>
>Why put restrictions on export that doesn't need to be there?
>We actually want to remove this checkout restriction, not propagate it
>to other things.
>
>
>
>>We have "svn cat" for that.
>>
>>
>
>By this argument, svn export is completely useless. You could make the
>directory structure on your own and cat into it one file at a time.
>
>Should we remove export because we have "cat for that", and instead tell
>people to script the equivalent?
>
>
Oh come on. :)
I'm merely suggesting that the solution to "export a single file" should
be the same as the solution to "checkout a single file".
In other words, if someone takes the time to teach export to create a
directory and put a single file in it, then we might as well do
something similar for checkout (fixing co -N first, of course). Until
then, I'd rather have export behave like checkout; if for no other
reason than it's easier to explain export as "checkout without creating
the .svn directories".
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Export behaving badly
Posted by Branko Čibej <br...@xbc.nu>.
Daniel Berlin wrote:
>On Mon, 2005-10-17 at 15:46 +0200, Branko Čibej wrote:
>
>
>>Daniel Berlin wrote:
>>
>>
>>
>>>So i'm converting over some documentation update scripts from gcc.
>>>
>>>They do the following:
>>>
>>>Export a bunch of doc files from repo
>>>build docs
>>>place them somewhere
>>>
>>>export, unfortunately, behaves differently than checkout. If you do
>>>
>>>svn export svn://gcc.gnu.org/svn/trunk/gcc/doc/install.texi gcc
>>>
>>>
>>>
>>>
>>I think export should simply fail for a single file, just like checkout.
>>
>>
>
>Checkout fails because it can't currently maintain a working copy
>alongside the single file
>
>Export doesn't fail because it doesn't need such a working copy.
>
>Why put restrictions on export that doesn't need to be there?
>We actually want to remove this checkout restriction, not propagate it
>to other things.
>
>
>
>>We have "svn cat" for that.
>>
>>
>
>By this argument, svn export is completely useless. You could make the
>directory structure on your own and cat into it one file at a time.
>
>Should we remove export because we have "cat for that", and instead tell
>people to script the equivalent?
>
>
Oh come on. :)
I'm merely suggesting that the solution to "export a single file" should
be the same as the solution to "checkout a single file".
In other words, if someone takes the time to teach export to create a
directory and put a single file in it, then we might as well do
something similar for checkout (fixing co -N first, of course). Until
then, I'd rather have export behave like checkout; if for no other
reason than it's easier to explain export as "checkout without creating
the .svn directories".
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Export behaving badly
Posted by Daniel Berlin <db...@dberlin.org>.
On Mon, 2005-10-17 at 15:46 +0200, Branko Čibej wrote:
> Daniel Berlin wrote:
>
> >So i'm converting over some documentation update scripts from gcc.
> >
> >They do the following:
> >
> >Export a bunch of doc files from repo
> >build docs
> >place them somewhere
> >
> >export, unfortunately, behaves differently than checkout. If you do
> >
> >svn export svn://gcc.gnu.org/svn/trunk/gcc/doc/install.texi gcc
> >
> >
> I think export should simply fail for a single file, just like checkout.
Checkout fails because it can't currently maintain a working copy
alongside the single file
Export doesn't fail because it doesn't need such a working copy.
Why put restrictions on export that doesn't need to be there?
We actually want to remove this checkout restriction, not propagate it
to other things.
> We have "svn cat" for that.
By this argument, svn export is completely useless. You could make the
directory structure on your own and cat into it one file at a time.
Should we remove export because we have "cat for that", and instead tell
people to script the equivalent?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Export behaving badly
Posted by Daniel Berlin <db...@dberlin.org>.
On Mon, 2005-10-17 at 15:46 +0200, Branko Čibej wrote:
> Daniel Berlin wrote:
>
> >So i'm converting over some documentation update scripts from gcc.
> >
> >They do the following:
> >
> >Export a bunch of doc files from repo
> >build docs
> >place them somewhere
> >
> >export, unfortunately, behaves differently than checkout. If you do
> >
> >svn export svn://gcc.gnu.org/svn/trunk/gcc/doc/install.texi gcc
> >
> >
> I think export should simply fail for a single file, just like checkout.
Checkout fails because it can't currently maintain a working copy
alongside the single file
Export doesn't fail because it doesn't need such a working copy.
Why put restrictions on export that doesn't need to be there?
We actually want to remove this checkout restriction, not propagate it
to other things.
> We have "svn cat" for that.
By this argument, svn export is completely useless. You could make the
directory structure on your own and cat into it one file at a time.
Should we remove export because we have "cat for that", and instead tell
people to script the equivalent?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Export behaving badly
Posted by Branko Čibej <br...@xbc.nu>.
Daniel Berlin wrote:
>So i'm converting over some documentation update scripts from gcc.
>
>They do the following:
>
>Export a bunch of doc files from repo
>build docs
>place them somewhere
>
>export, unfortunately, behaves differently than checkout. If you do
>
>svn export svn://gcc.gnu.org/svn/trunk/gcc/doc/install.texi gcc
>
>
I think export should simply fail for a single file, just like checkout.
We have "svn cat" for that.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Export behaving badly
Posted by Daniel Berlin <db...@dberlin.org>.
> The workaround would seem to be:
>
> $ mkdir gcc
> $ svn export file:///svn/gcc/trunk/gcc/doc/install.texi gcc/install.texi
>
Thanks, but i already know the workaround.
I want to fix the actual behavior, not work around it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Export behaving badly
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 17, 2005, at 02:30, Daniel Berlin wrote:
> export, unfortunately, behaves differently than checkout. If you do
>
> svn export svn://gcc.gnu.org/svn/trunk/gcc/doc/install.texi gcc
>
> It creates a file named "gcc" in the current directory, containing the
> contents of install.texi
>
> Fair enough, though different than checkout, which if you could
> checkout
> a single file, presumably would have put it in gcc
>
> So i create a dir named gcc
>
> -bash-3.00$ mkdir gcc
> -bash-3.00$ svn export file:///svn/gcc/trunk/gcc/doc/install.texi gcc
> svn: Can't move 'gcc.2.tmp' to 'gcc': Is a directory
>
> I *know* it's a directory.
> That's why i gave it to you. To put the file in.
>
> IMHO, export's extra argument should behave exactly like the one to
> checkout, and effectively copy the file into that path.
>
> The current behavior is just not sensible.
>
> We had a discussion about whether to create the empty paths that
> are in
> the URL or not (like CVS), and the consensus seemed to be no
>
> But nobody disagreed that what happens now doesn't match the checkout
> behavior, and probably should.
The workaround would seem to be:
$ mkdir gcc
$ svn export file:///svn/gcc/trunk/gcc/doc/install.texi gcc/install.texi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Export behaving badly
Posted by Branko Čibej <br...@xbc.nu>.
Daniel Berlin wrote:
>So i'm converting over some documentation update scripts from gcc.
>
>They do the following:
>
>Export a bunch of doc files from repo
>build docs
>place them somewhere
>
>export, unfortunately, behaves differently than checkout. If you do
>
>svn export svn://gcc.gnu.org/svn/trunk/gcc/doc/install.texi gcc
>
>
I think export should simply fail for a single file, just like checkout.
We have "svn cat" for that.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org