Another question about importing SVN with fast-import

> I have just hit a point where someone deleted a 
> directory, and then copied one of the files from that directory back from 
> an old revision (as two separate commits).  Since I'm not tracking any 
> branch contents in my front-end, and the copy operation only works from 
> the current branch head I seem to be stuck ... or have I missed something?

> Julian Phillips <julian@quantumfyre.co.uk> wrote:
>> However, how do you copy a file from a
>> particular revision?
>
> and sometimes not so much.  You can't do that right now.  I've wanted
> to open up the data subcommand to allow another form that lets you
> specify data from a branch and file path (thus selecting a blob
> from another revision) but I haven't gotten around to it.  I also
> don't have time to do it during the earlier part of this week.
> Maybe I'll get to it later near the end of the week.

>
> It shouldn't be too difficult now with the tree_content_get()
> function that I recently defined for the C/R commands.  The SHA-1
> comes back in the tree_entry leaf, but that codepath is only valid
> for the tip of a branch that fast-import knows about in memory.
> If it doesn't then you probably need to fallback into raw tree
> parsing.  Ugh.
>
> The way prior frontends have handled this is they assigned marks
> to every blob, and then had a translation table within the frontend
> of revision->mark, so that anytime it needed a given revision of a
> file it knew what mark to send to fast-import.  This does require
> that the frontend maintain basically everything...

> On Mon, 16 Jul 2007, Shawn O. Pearce wrote:
> 
> >Julian Phillips <julian@quantumfyre.co.uk> wrote:
> >>However, how do you copy a file from a
> >>particular revision?
> >
> >and sometimes not so much.  You can't do that right now.  I've wanted
> >to open up the data subcommand to allow another form that lets you
> >specify data from a branch and file path (thus selecting a blob
> >from another revision) but I haven't gotten around to it.  I also
> >don't have time to do it during the earlier part of this week.
> >Maybe I'll get to it later near the end of the week.
> 
> I was wondering if this was still a vague todo item, or if it was being 
> worked on?  It really is the biggest thing blocking my import at the 
> moment and I'm willing to have a bash at it myself, but I didn't want to 
> start messing around inside the fast-import code if someone else was 
> already there ...

> Now the question.  Shawn recently added C and R operations - almost as
> soon as they were asked for too.  However, how do you copy a file from a
> particular revision?  I have just hit a point where someone deleted a
> directory, and then copied one of the files from that directory back from
> an old revision (as two separate commits).  Since I'm not tracking any
> branch contents in my front-end, and the copy operation only works from
> the current branch head I seem to be stuck ... or have I missed something?

> On 7/16/07, Julian Phillips <julian@quantumfyre.co.uk> wrote:
> >Now the question.  Shawn recently added C and R operations - almost as
> >soon as they were asked for too.  However, how do you copy a file from a
> >particular revision?
> 
> I have to second Julian's question.

> This is kind of a request and a comment/question. The request is:
> there is no way to do *reasonably* in the front end what fast-import
> can do somewhat reasonably: namely, copy a <path> (file or directory!)
> from an arbitrary previously committed revision/mark to the current
> branch.

> The comment/question is: how different is this, really, from being
> able to  specify a "from" line in a commit? In both cases I'm asking
> fast-import to reach into its memory (or the repo) and pull out a
> tree, and to add (some or all of it) to my current branch. Isn't the
> kind of generic C command that Julian and I are asking for the same
> thing, only instead of taking the whole tree (from the specified
> commit) it takes a single file or directory?

> Lastly, do we really need "R"? With this generic copy - and I think
> there should be *only* a generic version, not a "streamlined local
> copy" version and a "reach into history arbitrarily" version - we can,
> as an earlier poster pointed out, do R by doing a C and then a D. This
> is, in fact, how svn dump files represent file and directory renames.

> David Frech <david@nimblemachines.com> wrote:
>> On 7/16/07, Julian Phillips <julian@quantumfyre.co.uk> wrote:
>>> Now the question.  Shawn recently added C and R operations - almost as
>>> soon as they were asked for too.  However, how do you copy a file from a
>>> particular revision?
>>
>> I have to second Julian's question.
>
> I'm getting to it.  Maybe this weekend.  Right now I have git-gui
> work to finish, and that work is more important to me this week than
> fast-import is.  Not that fast-import isn't important to me either,
> its just the way things are this week.

>> The comment/question is: how different is this, really, from being
>> able to  specify a "from" line in a commit? In both cases I'm asking
>> fast-import to reach into its memory (or the repo) and pull out a
>> tree, and to add (some or all of it) to my current branch. Isn't the
>> kind of generic C command that Julian and I are asking for the same
>> thing, only instead of taking the whole tree (from the specified
>> commit) it takes a single file or directory?
>
> It is possible.  I'm just not sure what the syntax for it should be.
> Suggestions?  I really want to stay backwards compatible with the
> current "C" command, so:
>
> 	'C' SP commit SP path SP path
>
> is out because its ambiguous with the current meaning where the
> second (destination) path can contain SP without being quoted by
> the frontend.

> On Fri, 20 Jul 2007, Shawn O. Pearce wrote:
>
> > It is possible.  I'm just not sure what the syntax for it should be.
> > Suggestions?  I really want to stay backwards compatible with the
> > current "C" command, so:
> >
> >       'C' SP commit SP path SP path
> >
> > is out because its ambiguous with the current meaning where the
> > second (destination) path can contain SP without being quoted by
> > the frontend.
>
> You could always make it part of the 'M' command?
>
> 'M' sp mode sp 'copy' sp path_str lf (ref_str | hexsha1 | sha1exp_str |
> idnum) SP path_str;
>
> Or just make it a new command, O (for other) or E (for existing) maybe? :S

>
> --
> Julian
>
>   ---
> It is easier to change the specification to fit the program than vice versa.
>

> On 7/19/07, Julian Phillips <julian@quantumfyre.co.uk> wrote:
>>  On Fri, 20 Jul 2007, Shawn O. Pearce wrote:
>> 
>> >  It is possible.  I'm just not sure what the syntax for it should be.
>> >  Suggestions?  I really want to stay backwards compatible with the
>> >  current "C" command, so:
>> > 
>> >        'C' SP commit SP path SP path
>> > 
>> >  is out because its ambiguous with the current meaning where the
>> >  second (destination) path can contain SP without being quoted by
>> >  the frontend.
>>
>>  You could always make it part of the 'M' command?
>>
>>  'M' sp mode sp 'copy' sp path_str lf (ref_str | hexsha1 | sha1exp_str |
>>  idnum) SP path_str;
>>
>>  Or just make it a new command, O (for other) or E (for existing) maybe? :S
>
> Since we'll be referring to past commits via marks (with start with
> ":") how about this:
>
> 'C' SP srcpath:mark SP dstpath

>
> In the case of making it a new command I can't think of any really
> compelling one letter names. ;-)
>
> - David
>
>>
>>  --
>>  Julian
>>
>>    ---
>>  It is easier to change the specification to fit the program than vice
>>  versa.
>> 
>
>

> On Thu, 19 Jul 2007, David Frech wrote:
> > Since we'll be referring to past commits via marks (with start with
> > ":") how about this:
> >
> > 'C' SP srcpath:mark SP dstpath
>
> Why only via marks?  That may be what you happen to want, but no other
> command restricts you to _only_ using marks ...

> --
> Julian
>
>   ---
> What say you, Mr. American Ambassador?
>
> Fuck Canada!
>

> It is possible.  I'm just not sure what the syntax for it should be.
> Suggestions?  I really want to stay backwards compatible with the
> current "C" command, so:
> 
> 	'C' SP commit SP path SP path
> 
> is out because its ambiguous with the current meaning where the
> second (destination) path can contain SP without being quoted by
> the frontend.