You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Joshua Varner <jl...@gmail.com> on 2006/01/11 20:14:40 UTC
Adding -c to export?
Introduction
The -c/--change option indicates that an action should be taken
on the "change set" for a given revision. I believe this makes sense
in the case of export, in that exporting a particular revision would
export only those files that have changed in that revision.
Motivation
I've seen a number of requests for the ability to export just the files
that have changed in a particular revision, e.g. for updating a web
site. Often the cost of the working copy or having a firewall keeps
the website from being a working copy, and using update.
Implementation Considerations (My thoughts in ()'s)
Should export -c create any intermediary directories required to
represent the files changed? (Yes)
Should the default be to overwrite any existing files? (Yes)
-----
I haven't done a lot of exporting, or even been in the situations I
am describing, but I have seen them brought up on users several
times. Given this design proposal is not terribly detailed, but if
accepted I can file an enhancement bug on this. So I guess this
falls more in to the errant thought category than design, but I
thought I would toss it out there.
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Adding -c to export?
Posted by Julian Foad <ju...@btopenworld.com>.
John Peacock wrote:
> Julian Foad wrote:
>
>> How would you propose to determine whether each file needs to be
>> updated, and, if so, which repository revision it currently matches?
>
> Require the use of -rOLD:NEW so that the caller is required to know
> beforehand what was the last rev exported.
Oh, duh! Of course, that's why it's related to the subject of this thread.
Sorry, I should have thought of that. That would be fine.
> Alternatively, do what SVK
> does and add custom tags to the repository describing the last export.
I can't imagine that working well. For one thing, it would have to try to
track uniquely each of the locations to which exports are performed. I'm not
sure if what SVK does with its merge info is at all comparable.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Adding -c to export?
Posted by John Peacock <jp...@rowman.com>.
Julian Foad wrote:
> How would you propose to determine whether each file needs to be
> updated, and, if so, which repository revision it currently matches?
Require the use of -rOLD:NEW so that the caller is required to know
beforehand what was the last rev exported. Alternatively, do what SVK
does and add custom tags to the repository describing the last export.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Adding -c to export?
Posted by Julian Foad <ju...@btopenworld.com>.
> Joshua Varner wrote:
>
> The -c/--change option indicates that an action should be taken
> on the "change set" for a given revision. I believe this makes sense
> in the case of export, in that exporting a particular revision would
> export only those files that have changed in that revision.
That's not a very close match to the present meaning of "--change". It
presently means "the change that was made", not "the set of files that were
changed". However, if we need that feature, the discussion of what
command-line syntax should invoke it is secondary.
I don't know whether we need that feature. It isn't a need that I have
encountered. We would probably also want to be able to export the set of files
that had changed over a given range of revisions.
John Peacock wrote:
> If export was exactly the same thing as checkout/update, minus the admin
> files, then it would be straightforward to support:
>
> svn export --update svn://url
>
> so that export could be used to *update* an existing exported tree.
How would you propose to determine whether each file needs to be updated, and,
if so, which repository revision it currently matches? Ideas:
* Use an rsync-like algorithm to update any data without even knowing
whether it matches any previous revision.
* Calculate a strong checksum (or "digest") of the file, and then search
backwards through the repository history of the file until finding that same
checksum? I suppose that would be safe enough and perhaps not slow in the
common cases.
* Do something with the file's time stamp. Not sure what exactly; I'm sure
we couldn't rely on it as an exact indicator of which revision the file matches.
[...]
> At all times, the information as to what files to delete, add, patch,
> etc. is available to do those on a admin-less export tree (with a little
> finesse to generate a virtual entries file).
Heh! You think it just needs "a little finesse"? Show us the code! :-)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Adding -c to export?
Posted by John Peacock <jp...@rowman.com>.
Joshua Varner wrote:
> I've seen a number of requests for the ability to export just the files
> that have changed in a particular revision, e.g. for updating a web
> site. Often the cost of the working copy or having a firewall keeps
> the website from being a working copy, and using update.
See:
http://search.cpan.org/dist/SVN-Notify-Mirror/
for way to get around firewall issues; you still need a working copy
someplace, though it could be a local one and use rsync vs. the remote
server. I'm thinking of writing a new transport method which would use
the Perl bindings to replicate the actions of an update vs. a remote
directory without requiring a working copy at all.
However, I've also been thinking about this from the Subversion end, but
in a different direction. I have previously complained that export
shares almost no code with update/checkout, even though it is almost
exactly the same thing (apart from writing admin files). There was at
least some positive noise from the core developers that making export
share more code with the other methods would be a Good Thing(TM).
If export was exactly the same thing as checkout/update, minus the admin
files, then it would be straightforward to support:
svn export --update svn://url
so that export could be used to *update* an existing exported tree.
Local updates would either cause a conflict (in this case the file would
not get updated), or --force could be used to overwrite local changes.
At all times, the information as to what files to delete, add, patch,
etc. is available to do those on a admin-less export tree (with a little
finesse to generate a virtual entries file).
It seems like the actions in update.c:svn_client__update_internal()
could be enhanced to create in-memory replicas of what the admin files
would look like (minus the text-base files).
Is this a pipe-dream?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org