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

[Jon Smirl]

On 10/28/06, Markus Schiltknecht <address@hidden> wrote:
> Hi,
>
> [ removed the cvs2svn ML, because I don't want to get into the cvs2svn
> import discussion, just a MTN-GIT naming issue
>
> Jon Smirl wrote:
> > Note that git is snapshot based, not change set based.
>
> I don't understand the difference here. AFAIK you have a snapshot (or
> revision) and apply a patch (or change set) to it to get another
> snapshot. Or how does git store snapshots?

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.

> > Git does not
> > need the base to be a single change set, it wants the base to be a
> > single snapshot.
>
> Right, as monotone wants the base to be a revision.
>
> > To do that there needs to be a point in the snapshot
> > sequence where a symbol can be inserted. If a rev created after the
> > symbol get combined into a snapshot in front of the symbol, it then
> > becomes impossible to insert the symbol and a branch has to be made.
>
> Huh? I don't understand what you mean here.

I posted a three commit example of the problem.

FileA has rev 1.1 and rev 1.2
FileB has rev 1.1
A symbol is created between A 1.1/1.2 and after B 1.1

cvs2svn generated two change sets
1) FileA 1.1
2) FileB 1.1, FileA 1.2

With these two change sets it is impossible to base the symbol simply,
there is no solution without copying. cvs2svn generates the symbol
based on #1 and copies FileB 1.1 from #2.

The alternative is to output three change sets which is also a valid
representation of the same data.
1) FileA 1.1
2) FileB 1.1
3) FileA 1.2

Now there is a solution for the symbol, base is on change set #2. No
copies needed.

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

> So you also added an artificial revision (or 'snapshot') to be able to
> tag multiple real revisions (real meaning committed together)?

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

--
Jon Smirl
address@hidden