[Monotone-devel] Re: Workspace merge?

[William Uther]

> "Zack Weinberg" <address@hidden> writes:
> > > 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.
> > 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.

I can see what you're saying.  There are a bunch of different types  
of conflicts, and I think
some could be easily handled with renames.  Some seem harder to  
handle with renames though.

> > 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 think it would be worthwhile to have conflicts in the roster as it  
allows conflicted
revisions in the database.  That means that 'merge' always  
'succeeds', and you get to fix the conflicts later.

My comment about not committing a conflicted file was along the lines  
of: only merge can create conflicted revisions, not commit.  It  
wasn't meant to say that I didn't think we should have conflicted  
revisions in the db.  ymmv.

Be well,

Will         :-}