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.
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
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,
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
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
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,
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
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).
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
It's been a while, but I'm back on the trail of workspace merge.
Summer of Code is formally over at this point, but UCSD doesn't start
back up until late September, so I intend to keep working until then.
(I probably won't have time after classes start, but you never know.)
I've made some but
This past week I worked on making _MTN/work hold a revision instead of
a changeset. Actually, I killed _MTN/work entirely, and _MTN/revision
too; the revision goes in _MTN/workrev. This makes it easy to tell
whether a workspace has the data in the old format. It does introduce
a flag day, but
My 'ooh shiny!' feature (diff -p) has made it to mainline, and I hope
that the multihead merge heuristic will follow soon. I've also got a
number of mails to respond to. I now consider myself sufficiently
familiar with the structure of the code that I can actually tackle the
real project, and
I'm still getting up to speed on the code. Last week I did one of the
quickie tasks, merging multiple heads with newer common ancestors
first; this is waiting for review on net.venge.monotone.multihead.
This week, on my local machine I have implemented diff -p support;
it's not ready for prime
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
14 matches
Mail list logo
