Re: [Monotone-devel] Re: monotone CVS import failed.

[Markus Schiltknecht]

Hi,

Jon Smirl wrote:
> Outside of a pack file git really does store snapshots. Each file in
> the snapshot is compressed with zlib. The snapshots are smart enough
> to share identical files using the sha1. There are no deltas.
>
> Inside a pack file git takes all the revisions of a file and sorts
> them from largest to smallest in size. It then xdiffs these and stores
> the deltas. There are no change sets or time sequential ordering.
>
> The directory trees are always snapshots, they just refer to the sha1
> of the expanded revisions. Inside a pack file the directories can
> sorted and xdiffed like the revisions, but it doesn't help that much.
>
> If you want a change set it can be constructed by taking two snapshots
> and diffing them. git provides tools for this.

Thank you for clarifying that. I've just read about git internals. I'm 
surprised they store full files and am wondering if monotone could do 
something similar, just for caching the data...

Or maybe that has to do with the delta vs. reverse delta vs. deltas with 
full files after 100 deltas discussion which netsync speedup has brought 
up. There is a wiki page about it, but I didn't find it...

Thinking about the full files as cached data might help. (?)

> By introducing symbol dependencies (which svn2cvs does not do) you can
> force the second change set sequence to be generated.

Uhm.. is there a reason for not adding such symbol dependencies? It 
seems obvious that branching and tagging should be handled by the 
toposort as well.

In monotone's cvs_import I'm adding such edges to the graph to be 
sorted, I just have troubles because I have to find out what branch 
symbols belong to *before* toposorting...

I've been thinking a lot about this chicken-and-egg problem. Currently 
I'm tempted to try to add another graph of just all the symbols and 
branches (but not the commits). Toposorting this one would allow me to 
clearly assign a tag or sub-branch to a certain branch. I don't know if 
it's worth it, though. The simple alternative would be to throw it all 
into one huge Graph.

> I don't want to do this, but it is a way to work around the problems
> in cvs2svn output.

For some tags you *have* to do this (or drop them).

Regards

Markus