Re: [Monotone-devel] Workspace merge?
On 11 Jul 2007, Zack Weinberg wrote:
The present state of play is, you can do 'mtn merge_into_workspace
revision' which will merge revision with the current workspace's
parent (I forget what happens if there are local changes; I think it
errors out) and dump the result into the workspace. You can mess
with that as you like and commit it once you're happy.
However, conflict resolution is just like 'mtn merge' -- if there
are file-content conflicts, you have to resolve them immediately,
and if there are name conflicts it errors out.
For the conflicts, I found it convenient to have a merger that leaves
the conflicts in the file, and returns true to mtn:
mergers.diff3_keep_conflicts = {
cmd = function (tbl)
local cmd =
diff3 --merge ..
-- Converting backslashes is necessary on Win32, since sh
-- string syntax says '\' is an escape.
string.format(--label \%s [left]\ , tbl.left_path) ..
string.format(--label \%s [ancestor]\ , tbl.anc_path) ..
string.format(--label \%s [right]\ ,tbl.right_path) ..
.. string.gsub (tbl.lfile, \\, /) ..
.. string.gsub (tbl.afile, \\, /) ..
.. string.gsub (tbl.rfile, \\, /) ..
.. string.gsub (tbl.outfile, \\, /)
local ret = execute(sh, -c, cmd)
return tbl.outfile
end,
available =
function ()
return program_exists_in_path(diff3) and
program_exists_in_path(sh);
end,
wanted =
function ()
return true
end
}
Then I can run Emacs smerge-ediff on each conflicted file to manually
resolve the conflicts before committing.
This also helps with propagate, although then the conflicted files are
committed. That's still better than having to resolve the conflicts
immediately.
Should I add this merger to std_hooks.lua? Obviously it should not be
in the list of automatic choices; the user can select it by setting
the MTN_MERGE environment variable.
Hmm. I guess I should rewrite it to use 'cmd' instead of 'sh', since
not everyone has Cygwin or even MinGW.
Or I could put it in contrib.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Workspace merge?
Zack Weinberg [EMAIL PROTECTED] writes:
branches? Do any work? Which are up-to-date?
...
No work has been done since the summit. The present state of play is,
you can do 'mtn merge_into_workspace revision' which will merge
revision with the current workspace's parent (I forget what happens
if there are local changes; I think it errors out) and dump the result
into the workspace. You can mess with that as you like and commit it
once you're happy.
Okie - This also needs to be added to the docs.
I don't want to put it in the official manual in its present state,
because it's little use as is and may change significantly before it's
done. You yourself propose some pretty radical changes ...
That said, it couldn't hurt to put more documentation of the present
state, and the roadmap to full functionality, on the wiki. I don't
have time to mess with it until next week, though.
What is still required to make it possible to merge in a
workspace?
I'm hoping to work on this some this summer, but I'd be very glad of
help. The next step is to write code that can take an arbitrary
conflicted roster_merge_result (see roster_merge.cc) and serialize it
into _MTN/conflicts (or some such file);
Hrm. For a first pass, I'd only allow is_clean_except_for_content()
stuff to be left in the workspace. If there are file-name conflicts
then you must resolve them at merge time. Actually, I'm not really
sure there is another good way to do this as you need to represent
things in the file system.
...
If you have a conflicted file in a roster, it is marked as conflicted
in the status output. You get four copies of the file in your
workspace: ancestor, left, right, and merged-with-conflict-markers
(respectively: myfile.ancestor.rev, myfile.revL, myfile.revR and
myfile). Once you've fixed the conflict, you run mtn resolved on
the file. It then has its conflict status in the roster resolved and
the three extra files in the workspace are removed.
I would actually say it is easier to do it the other way around.
There are many different kinds of name conflicts, but for each of
them, I believe it's possible to recover roster sanity by tacking a
canned sequence of renames onto each change set involved. The
existing namespace manipulation commands can then be used to resolve
the conflicts.
By contrast, file content conflicts require you to come up with
an entirely new mechanism for making the roster sane. We certainly
want all the files you listed to show up in the workspace, but which
of them get to be 'known' and which are just dumped there?
Tangentially, I want conflict marker generation to be left to a lua hook.
That restriction means you only need to handle file_content_conflicts.
My next thought is... can we actually leave the conflict marker in
the roster instead of a new file in the options/ directory? (Quick
terminology check: roster == list of files in a revision. Right? I
don't think I should be using the term manifest or revision from
revision.hh here.)
...
I'm not 100% sure what a 'sane' revision is. Is that equivalent to
saying it only has file content conflicts? If so, then that makes
perfect sense.
Roster means one of the data structures defined in roster.{cc,hh} and
stored in the 'rosters' and 'roster_deltas' tables in the database.
There is one roster per revision, and its content is a structured list
of files in that revision, plus mark-merge metadata, as I understand
it. The 'revision' structure (revision.{cc,hh}; 'revisions' and
'revision_ancestry' tables) is concerned with ancestry, not content.
Manifests are older, and I believe now used only in the netsync
protocol; they did the same job as rosters, but did not carry all of
the same information.
A roster is sane if and only if the check_sane() method on the
relevant roster_t object does not throw an invariant failure. A
roster resulting from an unclean merge is never sane; there are other
ways a roster can become insane, but I think they would all be bugs.
There is almost nothing you can do with an insane roster; check_sane()
is called by most roster operations. In particular, it cannot be
committed.
There is also check_sane_against(), which has to do with markings; I
confess I do not understand why 'marking_map' objects are separate
from 'roster_t' objects.
I would be very reluctant to put the conflict marker in the roster.
That data structure is complicated enough. I'd rather see a separate
serialization of the conflict list in the roster_merge_result,
indicating which changes to the workspace roster have been faked up to
remove conflicts.
I'd refuse to check in any revisions with a conflict in their roster.
Absolutely.
In future we could get more adventurous and allow the merge command to
commit revisions with conflicts in their rosters (although I'd keep
the restriction that users cannot commit conflicted files). That
Re: [Monotone-devel] Workspace merge?
Zack Weinberg [EMAIL PROTECTED] writes:
If you have a conflicted file in a roster, it is marked as conflicted
in the status output. You get four copies of the file in your
workspace: ancestor, left, right, and merged-with-conflict-markers
(respectively: myfile.ancestor.rev, myfile.revL, myfile.revR and
myfile). Once you've fixed the conflict, you run mtn resolved on
the file. It then has its conflict status in the roster resolved and
the three extra files in the workspace are removed.
I would actually say it is easier to do it the other way around.
There are many different kinds of name conflicts, but for each of
them, I believe it's possible to recover roster sanity by tacking a
canned sequence of renames onto each change set involved. The
existing namespace manipulation commands can then be used to resolve
the conflicts.
By contrast, file content conflicts require you to come up with
an entirely new mechanism for making the roster sane. We certainly
want all the files you listed to show up in the workspace, but which
of them get to be 'known' and which are just dumped there?
I would vote for ignoring the extra files, and listing the
conflicted one as known conflicted in 'automate inventory' in
nvm.basic_io.inventory (which needs to be merged with main soon).
Tangentially, I want conflict marker generation to be left to a lua
hook.
Yes, with a default to the CVS style.
Roster means one of the data structures defined in roster.{cc,hh} and
stored in the 'rosters' and 'roster_deltas' tables in the database.
There is one roster per revision, and its content is a structured list
of files in that revision, plus mark-merge metadata, as I understand
it. The 'revision' structure (revision.{cc,hh}; 'revisions' and
'revision_ancestry' tables) is concerned with ancestry, not content.
Manifests are older, and I believe now used only in the netsync
protocol; they did the same job as rosters, but did not carry all of
the same information.
Ah. So in the info manual in general, we should talk about rosters,
not manifests? I just rewrote the section for 'automate inventory'
in nvm.basic_io.inventory, using the term 'manifests'.
I would be very reluctant to put the conflict marker in the roster.
That data structure is complicated enough. I'd rather see a separate
serialization of the conflict list in the roster_merge_result,
indicating which changes to the workspace roster have been faked up to
remove conflicts.
I'm not clear how that would interact with 'automate inventory'; that
code gets all of it's information from rosters (I think).
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Workspace merge?
On Sat, Jul 14, 2007 at 05:23:32AM -0400, Stephen Leake wrote: Zack Weinberg [EMAIL PROTECTED] writes: Tangentially, I want conflict marker generation to be left to a lua hook. Yes, with a default to the CVS style. It will probably be with a default to call merge(1), like CVS does or even don't do them at all in the first version, because that lets us get the functionality out the door without rewriting our text conflict stuff to know how to generate conflicts... (right now it just aborts when it sees the first conflict). Manifests are older, and I believe now used only in the netsync protocol; they did the same job as rosters, but did not carry all of the same information. Ah. So in the info manual in general, we should talk about rosters, not manifests? I just rewrote the section for 'automate inventory' in nvm.basic_io.inventory, using the term 'manifests'. No, the manual should always (?) talk about manifests, because the manual is directed at users, not people hacking on monotone internals. Rosters are an detail of our optimized implementation; manifests are a stable textual format, part of our fundamental history representation. Manifests get signed, for instance (indirectly). (Actually, manifests are not even sent over netsync, at this point we don't even have code to parse a manifest in mtn proper...) I would be very reluctant to put the conflict marker in the roster. That data structure is complicated enough. I'd rather see a separate serialization of the conflict list in the roster_merge_result, indicating which changes to the workspace roster have been faked up to remove conflicts. I'm not clear how that would interact with 'automate inventory'; that code gets all of it's information from rosters (I think). It could get some information from _MTN/conflicts too, though, easy enough. -- Nathaniel -- If you can explain how you do something, then you're very very bad at it. -- John Hopfield ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] workspace merge status update
On 9/2/06, Nathaniel Smith [EMAIL PROTECTED] wrote: On Sat, Sep 02, 2006 at 08:50:02PM -0700, Zack Weinberg wrote: One thing doesn't make sense -- there is commentary on the need to fix up the absolute paths in _MTN/options of the saved workspaces, and there are indeed absolute paths in those files that don't exist on my computer, but I see no code to fix up the paths ... and yet the test succeeds on my computer. How is this possible? Ah, that could use some commenting... if you look carefully at the checks its doing, it doesn't compare the two options files byte-for-byte, it has some hardcoded regexes it scans for, with artfully placed .*'s. No, I mean, we go on to run monotone commands in the reconstituted working directory, I don't see how that is managing to work. (And it seems to me it would be good to do a little more -- compare automate inventory output, perhaps?) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] workspace merge status update
On Sun, Sep 03, 2006 at 12:59:47AM -0700, Zack Weinberg wrote: No, I mean, we go on to run monotone commands in the reconstituted working directory, I don't see how that is managing to work. (And it seems to me it would be good to do a little more -- compare automate inventory output, perhaps?) Because the 'mtn' function in the testsuite adds a whole bunch of extra arguments, including -d and --keydir. -- Nathaniel -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better one myself. -- Lord Jeffrey ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] workspace merge status update
On 9/2/06, Nathaniel Smith [EMAIL PROTECTED] wrote: On Sat, Sep 02, 2006 at 08:50:38PM -0700, Zack Weinberg wrote: What remains to be done before the branch can be merged? Whatever (if anything) is still outstanding from the last review, I guess. Plus perhaps that truncated comment in work_migration.cc that I noticed on IRC. Ok, I've fixed the comment, updated the manual, added a NEWS entry, and turned that weird thing in roster_t::get_attr() into an invariant check [which caused no regressions in the testsuite]. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] workspace merge status update
On Thu, Aug 31, 2006 at 02:50:14PM -0700, Zack Weinberg wrote: I've made some but not all of the changes Nathaniel requested to the .migration branch. The big remaining lack is that testing still doesn't work the way he wanted (mainly because I am having no luck figuring out how to do that). I wrote some tests as you requested -- see what you think :-). -- Nathaniel -- If you can explain how you do something, then you're very very bad at it. -- John Hopfield ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] workspace merge status update
On 9/2/06, Nathaniel Smith [EMAIL PROTECTED] wrote: On Thu, Aug 31, 2006 at 02:50:14PM -0700, Zack Weinberg wrote: I've made some but not all of the changes Nathaniel requested to the .migration branch. The big remaining lack is that testing still doesn't work the way he wanted (mainly because I am having no luck figuring out how to do that). I wrote some tests as you requested -- see what you think :-). Much appreciated. That looks quite nice. (I had no idea you could get() an entire directory tree, or I wouldn't have bothered with that gettree thing.) One thing doesn't make sense -- there is commentary on the need to fix up the absolute paths in _MTN/options of the saved workspaces, and there are indeed absolute paths in those files that don't exist on my computer, but I see no code to fix up the paths ... and yet the test succeeds on my computer. How is this possible? Also, must we have the 140-column separator lines? :-) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Workspace merge - weekly update
On Thu, 2006-07-06 at 00:27 -0700, Zack Weinberg wrote: Next I plan to tackle dusting off Tim's old code on net.venge.monotone.workspace-merge, reconstructing it in tune with more recent stuff, and breaking it up into mergeable chunks. There are global API changes in there which should make their way to mainline sooner rather than later. Just a note, all I got done there was changing _MTN/work from a cset (or path_rearrangement?) to a revision. Mostly this involved surgery on the restrictions code, so I stopped when I heard there was a rewrite of that code in progress. After it landed I never got around to looking at it, so I have no idea if any of what I did for workspace-merge is at all usable any more. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
