Re: [Monotone-devel] Time for a release
Thomas Keller [EMAIL PROTECTED] writes: Stephen Leake schrieb: I'm working on a minimal implementation of conflict resolution; just content and duplicate name conflicts. The duplicate name resolutions will only be rename or drop, not suture. The point of this conflict resolution implementation is to allow preparing conflict resolutions one at a time, before the actual merge command is issued. Then when you do the merge, you can tell it to use the prepared resolutions, so no user interaction is necessary. This avoids the problem of losing work when you encounter a conflict that's complicated and abort a merge. That sounds pretty cool already. Does this work for workspace merge as well, i.e. update? No, because 'mtn automate show_conflicts' doesn't show workspace conflicts, so there is no way to generate an appropriate conflicts resolution file. That could be improved in the future, but it will be a lot of work. We need to add new conflict classes for all the workspace conflicts, and change the way the core workspace update code to record the conflicts rather than just reporting them to stderr. You can always commit and merge before update, so this is not a major impediment. I'd like this to be in the next release so my team at work can use it, without an internal mtn version. I'd definitely like to have some people look over the code before it gets merged. Ok. The n.v.m.resolve_conflicts branch is only about half-done, but the general flavor is right, if people want to start looking at it. So if we can postpone a release until next weekend, I'd appreciate it. If the others are ok, I guess we can easily release a few days later. (After all, we've already waited four months...) My wife and son are away from Wednesday, so I guess I'll have more time for different things then anways ;) Ok. On the other hand, the mtn command line interface to this feature is not at all settled. snip Others have expressed a desire for mtn command line operations to add resolutions to the conflict file. I don't plan on using them, and we did not come to any consensus on what they might be, so I'm not implementing them now. A usable command line would probably be needed, otherwise people which don't use Emacs (like me) will find the interface then pretty academic and won't use it. I agree it is needed eventually. I'm not clear it is needed immediately. I'm undecided - even though I wear this nice release manager hat, I don't like to say just yes or no here. I perfectly understand that you need it for your team and that people should be encouraged testing it and all, but I fear that once the code went into mainline, the general (your?) interest making a halfway usable command line which does not include editing basic_io files is gone by then... That's true; holding merging this to mainline until there is a reasonable command line interface will definitely motivate me to implement it. And I agree that's a reasonable requirement. However, I was hoping that someone else would implement that part. Hmm. I guess it won't be too hard. There is already code that parses the basic-io conflicts representation and stores it in structures, and other code that writes out the structures; adding a command that just read them in, adds one or more resolutions, and writes them back out would not be hard. That same command could use the current need help for merge mechanism on content conflicts, one at a time. It will be difficult to let the user specify which conflict to work on. Always working on the first unresolved conflict would be reasonable, I guess. That way you would just provide resolutions in order; when there are resolutions for all conflicts, you are ready to merge. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
In message [EMAIL PROTECTED] on Sat, 30 Aug 2008 12:48:12 -0700, Zack Weinberg [EMAIL PROTECTED] said: zackw make distcheck is failing because it can't find a rule to create zackw mtnopt. This is a script which comes with the source tree; I tried zackw renaming it out of the util/ directory but that did not help. Whoever zackw created that file, please fix this. I'll look into it. If you look in Makefile.am in the top directory, you can find this: bin_SCRIPTS = mtnopt and this: # Support for scripts %: util/% cp $ $@ Famous words, I know, but it worked for me... What am I missing? zackw if everything looks reasonable sane, I'd do a release sometime on sunday. zackw zackw I've also done a couple of small updates to the Debian zackw packaging. Please DO NOT follow the instructions in zackw upgrade-checklist.txt for modifying debian/changelog; instead zackw just do zackw zackw $ dch -m --release Someone remind me where that file is... -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn2git issues
On Sun, Aug 31, 2008 at 4:19 PM, Felipe Contreras [EMAIL PROTECTED] wrote: On Sun, Aug 31, 2008 at 3:55 PM, Stephen Leake [EMAIL PROTECTED] wrote: Felipe Contreras [EMAIL PROTECTED] writes: On Sun, Aug 31, 2008 at 9:24 AM, Patrick Georgi [EMAIL PROTECTED] wrote: The only difference is that in git the changes in both branches of a merge are 'already done' so you can't do them again. So I guess what fast-import is doing is taking the changes strictly of the merge, and then the rest of the files are taken from the parents. The problem is defining what files were changed strictly by the merge. I suspect this means files that were modified from the common ancestor in both parents, and thus needed file merging during the revision merge. You can identify such files in the output of get_revision; they are the ones that appear in both changesets. Yes, I'm trying your suggestion right now. Good idea. However, if the result of the file merge is identical to one of the parents (due to user choices during the file merge), then maybe it's not considered modified during the merge? So you have to look at the file ids, and compare them to the file ids in the parent revisions. I don't see an operation for that in mtn automate; it would be something like: mtn automate get_file_id revision filename or maybe (slightly faster): mtn automate get_corresponding_file_id current_revision file_id revision Right now I'm fetching the whole contents of the file anyway, git would check if the file has changed or not. In order compare the file ids of a revision to the parents I would have to either a) keep the whole tree of every revision, or b) use get_file_id for the revision and both parents. I assume it would be more efficient to do b), but would 3 calls to get_file_id be more efficient than just grabbing the whole file contents? Maybe a get_revision_changes command would make sense; it does the 3 get_file_id gets, makes the comparison and generates a stripped down version. Ok, instead of generating the right output I modified git fast-import to drop bad changes. It seems to work fine. Best regards. -- Felipe Contreras ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Mon, Sep 1, 2008 at 12:10 AM, Richard Levitte [EMAIL PROTECTED] wrote: Zack Weinberg [EMAIL PROTECTED] said: zackw make distcheck is failing because it can't find a rule to create zackw mtnopt. I'll look into it. If you look in Makefile.am in the top directory, you can find this: bin_SCRIPTS = mtnopt and this: # Support for scripts %: util/% cp $ $@ Famous words, I know, but it worked for me... What am I missing? Possibly just needs putting util/mtnopt in EXTRA_DIST or whatever it's actually called then? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Zack Weinberg wrote: On Mon, Sep 1, 2008 at 12:10 AM, Richard Levitte [EMAIL PROTECTED] wrote: Zack Weinberg [EMAIL PROTECTED] said: zackw make distcheck is failing because it can't find a rule to create zackw mtnopt. I'll look into it. If you look in Makefile.am in the top directory, you can find this: bin_SCRIPTS = mtnopt and this: # Support for scripts %: util/% cp $ $@ Famous words, I know, but it worked for me... What am I missing? Possibly just needs putting util/mtnopt in EXTRA_DIST or whatever it's actually called then? Already fixed 'make distcheck' by moving mtnopt from bin_SCRIPTS to dist_bin_SCRIPTS, adding it to DISTCLEANFILES, and patching it to support '-- help' and '--version' ;) - Thomas signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] any_path, bookkeeping_path, file_path
In specifying conflict resolutions, the user can specify a file that
contains the desired content.
I'd like to allow that file to either be in the workspace, or in the
bookkeeping area (or anywhere else, for that matter). That gives the
user maximum flexibility in designing a workflow.
However, I don't see how to do that nicely. There are two problems;
converting a std::string to an arbitrary path, and storing external
file names in basic-io format.
I'm just discovering this now, because all my tests so far have had
the user file in the workspace, but for the real Emacs DVC process, it
makes more sense to have it in the bookkeeping area.
First, I can store a std::string in the conflict resolution data. But
when it comes time to read that file, I had to do this:
if (bookkeeping_path::external_string_is_bookkeeping_path
(utf8(conflict.resolution.second)))
{
bookkeeping_path p(conflict.resolution.second);
read_data(p, result_raw_data);
}
else
{
file_path p(file_path_external(utf8(conflict.resolution.second)));
read_data(p, result_raw_data);
}
because there is no way to construct an 'any_path' object from a
string.
Second, the basic-io format assumes internal representation of file
paths: push_file_pair outputs file_path.as_internal().
So I'm using push_str_pair instead, with the raw user-supplied file
name, and handling the conversion to any_path only when it's actually
needed, as above. I'm not sure that's acceptable.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] any_path, bookkeeping_path, file_path
On Mon, Sep 1, 2008 at 12:06 PM, Stephen Leake [EMAIL PROTECTED] wrote: In specifying conflict resolutions, the user can specify a file that contains the desired content. I'd like to allow that file to either be in the workspace, or in the bookkeeping area (or anywhere else, for that matter). That gives the user maximum flexibility in designing a workflow. Did you try using a system_path? That seems like a better fit for what you're trying to do. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] any_path, bookkeeping_path, file_path
Zack Weinberg [EMAIL PROTECTED] writes: On Mon, Sep 1, 2008 at 12:06 PM, Stephen Leake [EMAIL PROTECTED] wrote: In specifying conflict resolutions, the user can specify a file that contains the desired content. I'd like to allow that file to either be in the workspace, or in the bookkeeping area (or anywhere else, for that matter). That gives the user maximum flexibility in designing a workflow. Did you try using a system_path? No, because I didn't know about them. One of these days, I'll actually read _all_ of the current code :). That seems like a better fit for what you're trying to do. As usual, I stumbled across system paths just before reading your email. Sorry for the noise. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
I've just committed db337bc730cc15eae78f94a423bc460823b07e0a. It adds the command 'resolve_conflict' that sets the conflict resolution for the first unresolved conflict in the conflict file. There's a test for it, which isn't passing yet, because it's testing conflict resolutions that are not yet implemented. I also added a command 'automate file_merge' that outputs the result of the internal line merger; useful for checking what a 'resolved_internal' file content conflict will actually be. It's bedtime for today. I have some time tomorrow; I might actually finish the todo list for this. Argh; I forgot to put 'resolve_conflict' in monotone.texi. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
