monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] rewrite of checkout to use editable_working_tree


From: Derek Scherger
Subject: [Monotone-devel] rewrite of checkout to use editable_working_tree
Date: Wed, 27 Dec 2006 23:32:19 -0700
User-agent: Thunderbird 1.5.0.9 (X11/20061221)

I've just pushed a new branch net.venge.monotone.editable_tree.checkout that rewrites checkout in terms of editable_working_tree. The point of this is to allow checkout to take advantage of the workspace conflict resolution machinery, once it is written.

Of course I am assuming that people do want checkout to be able to deal with workspace conflicts and not just clobber anything that gets in its way. I guess we'll see whether this is a good assumption or not . ;)

Hopefully this will also add some detail to what the "workspace conflict resolution machinery" should eventually look like. There are at least 3 conflict cases that checkout may encounter:

1. create_dir_node will fail if _MTN/tmp/<nid> already exists in the workspace. I'm not sure how we would respond to such an error, other than requesting that the user clean up their _MTN/tmp dir?

2. create_file_node will fail if _MTN/tmp/<nid> already exists in the workspace, although this failure is somewhat pointless at the moment. The get_linesep_conv and get_charset_conv hooks require that files aren't created until their path is known, which isn't the case until attach_node executes, so the actual creation is deferred to attach_node which seems a bit ugly. Ideally, we should be able to do away with these hooks if character set and line ending style are specified as attributes. Again, I'm not sure how we'd respond to this error.

3. attach_node will fail if the path it wants to attach a node to already exists in the workspace that checkout is creating. Currently checkout simply clobbers files as required, although I believe it will fail if a file is blocked by a directory or vice-versa. I'll start another thread to discuss how attach_node conflicts might be handled.

These are just three cases that come to mind but it won't surprise me if there are other things that can go wrong.

This new version of checkout appears to be functional, only a few tests needed updating, but it is considerably slower than what we currently have and is also considerably more verbose. Stock checkout of net.venge.monotone takes ~1.164s while the new checkout takes ~8.344s on my laptop. Stock checkout produces no output at all, while the new checkout writes "mtn: adding ..." for each file and directory that it creates, 1955 lines in total.

If anyone is set up to do profiling and has a chance I'd be interested to see where the time is going. I'll probably have a go at this myself at some point too but it may be a while.

Cheers,
Derek




reply via email to

[Prev in Thread] Current Thread [Next in Thread]