RFC: workingdir

Dirkjan Ochtman dirkjan at ochtman.nl
Sun Jun 6 07:08:07 CDT 2010


Matt was fighting with the circular imports, and I looked around a bit
at some parts of the code. I came up with an idea for disentangling
some of the working dir-related stuff from the localrepo class (and
the hg module). Herewith some ideas on what's feasible to separate up
into a separate class; we should be able to decide if it's worth doing
from my notes.

My idea is to have a higher-level class representing the working
directory. This could be a layer in between repo and dirstate, so that
we have repo.wdir.dirstate. Ideally, the workingdir class would not
know about the repo, though that's really the tricky part, and maybe
an object cycle isn't so bad in this case (if it *is* allowed to know
about the repo, that opens up more stuff we can put in there).

Anyway, I think this is a bunch of stuff from localrepo we could put
in there, and their dependencies:

filterpats
_datafilters
wopener         root
wjoin           root
dirstate        opener, ui, root
getcwd          dirstate
pathto          dirstate
wfile           wopener
_link           wjoin
_filter         filterpats, ui, _datafilters, root, self
adddatafilter   _datafilters
wread           _link, _filter, wjoin, wopener
wwrite          _filter, wjoin, wopener
wwritedata      _filter
wlock           dirstate, _wlockref, origroot, join
forget          dirstate, wlock, ui
remove          dirstate, wlock, ui
undelete        manifest, changelog, dirstate, wlock, ui, wwrite
copy            wjoin, ui, wlock, dirstate

As you can see, this is mostly very consistent, and could make a nice
unit. undelete may a bit harder, but it seems that it's only used for
qrename in versioned repositories, so maybe we can just get rid of it.

I was also interested (from a conceptual level) in putting the
following from localrepo into workingdir, but that might be harder:

commit          __getitem__, root, wlock, status, dirstate, commitctx,
pathto, ui, hook
status          __getitem__, root, getcwd, ui, dirstate, wlock

These really need to have a repository around.

There is some API in the hg module that I think is very old that I
think would be a good fit for the workingdir class conceptually:

_showstats      repo.ui
update          merge.update, wlock, workingctx, dirstate
clean           merge.update
merge           merge.update
revert          merge.update

But it turns out that merge.update() and everything that it calls
really needs a repo (it calls repo.hook, copies.copies,
subrepo.submerge), too, so maybe there's not much point. Actually
revert is a one-liner with two users, so it might not hurt to just get
rid of the function entirely. There's also hg.verify() which is just
verify.verify(repo) and also has two users, so that's also something
we can likely clean up. merge, update, clean have 5, 6 and 14 users
respectively.

What do we think?

Cheers,

Dirkjan


More information about the Mercurial-devel mailing list