[Monotone-devel] Re: current multiple heads (was Re: write access to my public server)

[Asger Ottar Alstrup]

graydon hoare wrote:
> well, our current representation is *implemented* this way -- one bucket 
> of edge-describing metadata, one bucket of content-describing deltas -- 
> we just don't have particularly convenient names for edges, other than 
> naming their endpoints. that has the benefit of simplicity, though, as 
> well as letting you name "edges" which were never actually recorded by a 
> user in a database (say, spanning several versions).

OK, I see.

> > In other words, all users 
> > should have the full DAG, but can omit many of the patches themselves.
>
> I think from a UI perspective this is undesirable. maybe I'm wrong, but 
> my experience so far has been that "knowing what you have on disk" lends 
> the program an important sense of comfort. nobody likes a VC system 
> telling them a particular state is unconstructable. it's almost better 
> not to know about that state.

The point was that this could be configurable per user. If a user has 
the capacity to keep an entire repository along with the complete 
history, he would not use a compression policy.

However, if monotone has to scale to big repositories with long 
histories, I think it is important to provide some ways to trim the 
history to make it scale.

Consider putting the Linux source code repository under monotone. 
Without any history compression support, a check-out of that would be 
hundreds of megabytes, and take correspondingly long time.

And as written earlier, we have several CVS repositories of several GBs. 
It is not realistic to require that everybody needs to replicate this in 
order to check in a one-line change someone.

But as I read your comments, it should in fact be possible to implement 
some kind of compression support using the existing data structure. That 
is good news.

> anyways, I think we have a sufficiently workable solution to the 
> motivating problem here (possible cycles due to reversion, and the 
> breaking thereof), so I'm going to pass on redoing the underlying 
> representation.

OK, I understand that this is a separate issue. I did not read the 
details of your discussion, but I believe that a solution might be to 
use unique IDs for the nodes in your DAG. That will prevent cycles in 
this scenario. This is an old discussion, so we do not have to open that 
again.

Regards,
Asger