Re: fast-import issues with monotone

["Felipe Contreras" <felipe.contreras@gmail.com>]

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