fast-import issues with monotone

fast-import issues with monotone

[Felipe Contreras]

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

Re: fast-import issues with monotone

[Shawn O. Pearce]

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.
 
> 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.

Re: fast-import issues with monotone

[Felipe Contreras]

On Tue, Sep 9, 2008 at 1:36 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> 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 :)

>> 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.

>> 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