threads / discuss / 15439

fast-import issues with monotone

Subject: fast-import issues with monotone

## tl;dr

3 messages between Sep 8, 2008 and Sep 8, 2008.

replies: 2people: 2as markdown or json

Felipe Contreras· Sep 8, 2008, 22:30 UTC · lore

Hi,

I'm stuck with yet another issue while trying to export a mtn repository, so I thought on sharing the list of issues:

a) directory rename/deletes are indistinguishable from files

This means directories must be tracked by the generator to find out if the operation is on a file, or a directory. If it's in a directory then the operation should be executed in all the files that are under that directory.

It's possible to find out the whole tree of a revision, but it's a *very* expensive operation (takes about a second).

b) file mode changes are just like any other operation (you don't get the mode at each revision)

This means the file mode needs to be tracked all the time. Also, it means the file contents (blob) needs to be tracked because sometimes the only change in the file is the mode.

Again, retrieving the whole tree is possible, but expensive.

There are other issues, but not so important.

For these two issues the only viable solution is to keep track of the whole tree of each revision. Does it makes sense to do that? Or would it make more sense to modify fast-import to allow more delta-oriented operations?

-- 
Felipe Contreras

Shawn O. Pearce· Sep 8, 2008, 22:36 UTC · re: Felipe Contreras · lore

Re: fast-import issues with monotone

Felipe Contreras <felipe.contreras@gmail.com> wrote:

> I'm stuck with yet another issue while trying to export a mtn
> repository, so I thought on sharing the list of issues:
> 
> a) directory rename/deletes are indistinguishable from files

Hmm.  I had thought fast-import allowed you to rename or delete a
directory by just name its path.  Internally it should be cascading
those operations to all of the contained children.

Show 6 quoted lines

> b) file mode changes are just like any other operation (you don't get
> the mode at each revision)
> 
> This means the file mode needs to be tracked all the time. Also, it
> means the file contents (blob) needs to be tracked because sometimes
> the only change in the file is the mode.

Ow. I could see a special case being introduced into the language as placeholders for the fields, telling gfi not to replace the data if it is already present. Probably not even a very difficult patch to add. E.g. make "-" a placeholder for both mode and content SHA-1/mark.

> For these two issues the only viable solution is to keep track of the
> whole tree of each revision. Does it makes sense to do that? Or would
> it make more sense to modify fast-import to allow more delta-oriented
> operations?

Most frontends do keep track of everything. The CVS->Git and CVS->SVNish->Git keep track of everything just so they can order things across files to form commits/changesets.

-- 
Shawn.

Felipe Contreras· Sep 8, 2008, 23:37 UTC · re: Shawn O. Pearce · lore

Re: fast-import issues with monotone

On Tue, Sep 9, 2008 at 1:36 AM, Shawn O. Pearce <spearce@spearce.org> wrote:

Show 9 quoted lines

> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> I'm stuck with yet another issue while trying to export a mtn
>> repository, so I thought on sharing the list of issues:
>>
>> a) directory rename/deletes are indistinguishable from files
>
> Hmm.  I had thought fast-import allowed you to rename or delete a
> directory by just name its path.  Internally it should be cascading
> those operations to all of the contained children.

Aha! I didn't notice that. I guess I assumed 'filedelete' was for files only :)

Show 12 quoted lines

>> b) file mode changes are just like any other operation (you don't get
>> the mode at each revision)
>>
>> This means the file mode needs to be tracked all the time. Also, it
>> means the file contents (blob) needs to be tracked because sometimes
>> the only change in the file is the mode.
>
> Ow.  I could see a special case being introduced into the language as
> placeholders for the fields, telling gfi not to replace the data if
> it is already present.  Probably not even a very difficult patch
> to add.  E.g. make "-" a placeholder for both mode and content
> SHA-1/mark.

Yeap, I thought about something that. I'll implement it then.

Show 8 quoted lines

>> For these two issues the only viable solution is to keep track of the
>> whole tree of each revision. Does it makes sense to do that? Or would
>> it make more sense to modify fast-import to allow more delta-oriented
>> operations?
>
> Most frontends do keep track of everything.  The CVS->Git and
> CVS->SVNish->Git keep track of everything just so they can order
> things across files to form commits/changesets.

Well, CVS/SVN are special cases, are they using fast-import? In any case, I guess there's no way to make those generators simple, but I don't think for DSCMs generators should be that complicated.

-- 
Felipe Contreras