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

Re: SVN export command irregularity

From: Adam Grant <adam.grant_at_telaeris.com>
Date: Fri, 12 Jun 2009 16:36:54 -0700


Thank you for your help! Yeah, the docs could better explain that, since a
deeper knowledge of what exactly `svn checkout` does is required to
interpret that. So if the revision you checked out is the same as the one
specified by `-r REV`, then it will use the working copy. Gotcha. And so
HEAD is a Master repo specific idea, which the working copy cannot guess. I
appreciate your quick and thorough responses! I can see why this community
has thrived :)


Adam Grant
Lead Web Engineer
Telaeris, Inc.
(858) 627-9710
On Fri, Jun 12, 2009 at 4:24 PM, Ryan Schmidt <
subversion-2009b_at_ryandesign.com> wrote:
> On Jun 12, 2009, at 11:24, Adam Grant wrote:
>  Your explanation makes sense. Going back and re-reading the red-bean docs
>> shows this:
>> svn export [-r REV] URL [PATH]svn export PATH1 PATH2
>> I didn't realize the [-r REV] only applied to the first case, which does
>> go to the MASTER repo. I assumed that if I specified `svn export -r HEAD
>> PATH1 PATH2` without giving it a full URL, then it would export from the
>> local, working copy whatever it thought it's "HEAD" was. And if it didn't
>> export from the working copy, I expected it to balk when it saw the `-r
>> HEAD`, since that seems to only apply to export commands if given a URL.
>> But, checking out the command line, I notice my `svn export --help` says
>> this (this is what I originally read):
>> ====================
>> usage: 1. export [-r REV] URL[@PEGREV] [PATH]
>>       2. export [-r REV] PATH1[@PEGREV] [PATH2]
>>  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.
>>  2. Exports a clean directory tree from the working copy specified by
>>     PATH1, at revision REV if it is given, otherwise at WORKING, into
>>     PATH2.  If PATH2 is omitted, the last component of the PATH1 is used
>>     for the local directory name. If REV is not specified, all local
>>     changes will be preserved.  Files not under version control will
>>     not be copied.
>> ====================
>> Now this doc leads me to my old train of thought, whereas the red-bean
>> book disagrees with this. Here they say even if you give it a revision, it
>> will export from the working copy. But it doesn't. I've tried. It goes to
>> the repo. Maybe my understanding of subversion isn't that deep, so could it
>> be if the local working copy doesn't have knowledge of the revision you pass
>> it, it goes to the MASTER repo, like you suggested, even for HEAD? It seems
>> screwy to document it like this and then ignore the working copy no matter
>> which form you use if you tack on `-r REV.
>> Does it seem like I'm interpreting this correctly?
> I think the help text printed by svn help could use some refinement. I
> think the fact is that if you want to export what is in a working copy, then
> you export from the working copy, and you do not specify a revision. If you
> want a specific revision, you export from a working copy or a URL, and it
> will connect to the repository to get the revision you asked for.
> A working copy only contains the revision of files it contains; it doesn't
> contain the whole history. And unless you just ran "svn up" on the
> repository, likely not all files are at the same revision (see mixed
> revision working copies). So it would be unlikely for "svn export -r REV"
> against a working copy to be able to give you that rev you specified, unless
> the working copy is already at that revision, in which case you don't need
> to specify the revision.
> In your case of -r HEAD, the only way to accurately determine what HEAD
> means is to ask the repository.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-13 01:38:37 CEST

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