On Thu, 3 Aug 2006, Linus Torvalds wrote: > > Sure. In that case, just list the object ID's in the exact same order you > created them. Btw, you still want to give a filename for each object you've created, so that the delta sorter does the right thing for the packing. It doesn't have to be a _real_ filename - just make sure that each revision that comes from the same file has a filename that matches all the other revisions from that file. What the filename actually _is_ doesn't much matter, and it doesn't have to be the "real" filename that was associated with that set of revisions, since we'll just end up hashing it anyway. So it could be some "SVN inode number" for that set of revisions or something, for all git-pack-object cares. So you could just go through each SVN file in whatever the SVN database is (I don't know how SVN organizes it), generate every revisions for that file, and pass in the SVN _database_ filename, rather than necessarily the filename that that revision is actually associated with when checked out. So for example, if SVN were to use the same kind of "Attic/filename,v" format that CVS uses, there's no reason to worry what the real filename was in any particular checked out tree, you could just pass git-pack-objects a series of lines in the form of .. <sha1-object-name-of-rev1> Attic/filename,v <sha1-object-name-of-rev2> Attic/filename,v <sha1-object-name-of-rev3> Attic/filename,v .. as input on its stdin, and it will create a pack-file of all the objects you name, and use the "Attic/filename,v" info as the deltifier hint to know to do all the deltas of those revs against each other rather than against random other objects. The fact that the file was actually checked out as "src/filename" (and, since SVN supports renaming, it might have been checked out under any number of _other_ names over the history of the project) doesn't matter, and you don't need to even try to figure that out. git-pack-objects wouldn't care anyway. Linus - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html