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
Felipe Contreras [off-list ref] 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.
On Tue, Sep 9, 2008 at 1:36 AM, Shawn O. Pearce [off-list ref] wrote:
Felipe Contreras [off-list ref] wrote:
quoted
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 :)
quoted
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.
quoted
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