{"thread":{"id":"15439","subject":"fast-import issues with monotone","startedAt":"2008-09-08T22:30:39Z","lastAt":"2008-09-08T23:37:20Z","messageCount":3,"participants":["Felipe Contreras","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"90142","messageId":"94a0d4530809081530p60ff8692qbf9c314516d03869@mail.gmail.com","threadId":"15439","inReplyTo":null,"subject":"fast-import issues with monotone","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-09-08T22:30:39Z","receivedAt":"2008-09-08T22:30:39Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nI'm stuck with yet another issue while trying to export a mtn\nrepository, so I thought on sharing the list of issues:\n\na) directory rename/deletes are indistinguishable from files\n\nThis means directories must be tracked by the generator to find out if\nthe operation is on a file, or a directory. If it's in a directory\nthen the operation should be executed in all the files that are under\nthat directory.\n\nIt's possible to find out the whole tree of a revision, but it's a\n*very* expensive operation (takes about a second).\n\nb) file mode changes are just like any other operation (you don't get\nthe mode at each revision)\n\nThis means the file mode needs to be tracked all the time. Also, it\nmeans the file contents (blob) needs to be tracked because sometimes\nthe only change in the file is the mode.\n\nAgain, retrieving the whole tree is possible, but expensive.\n\n\nThere are other issues, but not so important.\n\nFor these two issues the only viable solution is to keep track of the\nwhole tree of each revision. Does it makes sense to do that? Or would\nit make more sense to modify fast-import to allow more delta-oriented\noperations?\n\n-- \nFelipe Contreras\n"},{"id":"90143","messageId":"20080908223601.GB14448@spearce.org","threadId":"15439","inReplyTo":"94a0d4530809081530p60ff8692qbf9c314516d03869@mail.gmail.com","subject":"Re: fast-import issues with monotone","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-09-08T22:36:01Z","receivedAt":"2008-09-08T22:36:01Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Felipe Contreras wrote:\n> I'm stuck with yet another issue while trying to export a mtn\n> repository, so I thought on sharing the list of issues:\n> \n> a) directory rename/deletes are indistinguishable from files\n\nHmm. I had thought fast-import allowed you to rename or delete a\ndirectory by just name its path. Internally it should be cascading\nthose operations to all of the contained children.\n \n> b) file mode changes are just like any other operation (you don't get\n> the mode at each revision)\n> \n> This means the file mode needs to be tracked all the time. Also, it\n> means the file contents (blob) needs to be tracked because sometimes\n> the only change in the file is the mode.\n\nOw. I could see a special case being introduced into the language as\nplaceholders for the fields, telling gfi not to replace the data if\nit is already present. Probably not even a very difficult patch\nto add. E.g. make \"-\" a placeholder for both mode and content\nSHA-1/mark.\n\n> For these two issues the only viable solution is to keep track of the\n> whole tree of each revision. Does it makes sense to do that? Or would\n> it make more sense to modify fast-import to allow more delta-oriented\n> operations?\n\nMost frontends do keep track of everything. The CVS->Git and\nCVS->SVNish->Git keep track of everything just so they can order\nthings across files to form commits/changesets.\n\n-- \nShawn.\n"},{"id":"90150","messageId":"94a0d4530809081637g23543c41w28e6039a75b85fa2@mail.gmail.com","threadId":"15439","inReplyTo":"20080908223601.GB14448@spearce.org","subject":"Re: fast-import issues with monotone","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-09-08T23:37:20Z","receivedAt":"2008-09-08T23:37:20Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Sep 9, 2008 at 1:36 AM, Shawn O. Pearce wrote:\n> Felipe Contreras wrote:\n>> I'm stuck with yet another issue while trying to export a mtn\n>> repository, so I thought on sharing the list of issues:\n>>\n>> a) directory rename/deletes are indistinguishable from files\n>\n> Hmm. I had thought fast-import allowed you to rename or delete a\n> directory by just name its path. Internally it should be cascading\n> those operations to all of the contained children.\n\nAha! I didn't notice that. I guess I assumed 'filedelete' was for files only :)\n\n>> b) file mode changes are just like any other operation (you don't get\n>> the mode at each revision)\n>>\n>> This means the file mode needs to be tracked all the time. Also, it\n>> means the file contents (blob) needs to be tracked because sometimes\n>> the only change in the file is the mode.\n>\n> Ow. I could see a special case being introduced into the language as\n> placeholders for the fields, telling gfi not to replace the data if\n> it is already present. Probably not even a very difficult patch\n> to add. E.g. make \"-\" a placeholder for both mode and content\n> SHA-1/mark.\n\nYeap, I thought about something that. I'll implement it then.\n\n>> For these two issues the only viable solution is to keep track of the\n>> whole tree of each revision. Does it makes sense to do that? Or would\n>> it make more sense to modify fast-import to allow more delta-oriented\n>> operations?\n>\n> Most frontends do keep track of everything. The CVS->Git and\n> CVS->SVNish->Git keep track of everything just so they can order\n> things across files to form commits/changesets.\n\nWell, CVS/SVN are special cases, are they using fast-import? In any\ncase, I guess there's no way to make those generators simple, but I\ndon't think for DSCMs generators should be that complicated.\n\n-- \nFelipe Contreras\n"}]}