Project plans

Matt Mackall mpm at selenic.com
Tue Sep 27 12:27:50 CDT 2005


On Tue, Sep 27, 2005 at 08:05:51AM -0400, Kevin Smith wrote:
> Matt Mackall wrote:
> >On Mon, Sep 26, 2005 at 10:47:07PM -0400, Kevin Smith wrote:
> >
> >>So, just to confirm: there are no plans in the near future for Mercurial 
> >>to support any kind of "centralized storage", "patch pooling", or other 
> >>mechanisms that would allow lightweight branching without hardlinks?
> >
> >Well I haven't personally been thinking about it much as I'm focused
> >on getting the current feature set in a releasable form, and I haven't
> >seen a proposal for how to do it that's really caught my eye.
> 
> Ok.
> 
> >Don't tell anyone, but you can actually do "centralized storage"
> >already (in a CVS-like fashion), with an appropriate set of symlinks.
> >Doing this a bit more sanely with appropriate locking and so on is
> >easily achievable with an extension.
> 
> Um. I guess I need to amend my request to "...without hardlinks OR 
> symlinks", since FAT filing systems have neither.

The current repository structure is like this:

repo.root -> pointer to top of working dir
repo.path -> pointer to repo data

We can't share all of the repo data. Specifically we can't share the
dirstate or the undo.dirstate information. And we probably don't want
to share the .hgrc info.

So we need to add a third path in localrepository.__init__. Something
like repo.localpath. This points to .hg/. And repo.path continues to
point to the same place unless we override it in .hg/hgrc to point to
a shared directory. And then audit all the uses of repo.path. And then
add a "share" command.

If someone writes this, I might actually include it. But it's not
without problems. In particular, people will try to use it with
multiple users and will complain about the non-CVS-like behavior where
each user's commit creates a new head.

-- 
Mathematics is the supreme nostalgia of our time.


More information about the Mercurial mailing list