bugmonotone - Bugs: bug #21822, [Fixed in 0.20] Inappropriate...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #21822: [Fixed in 0.20] Inappropriate logic & design of manual merge enforcement

Submitted by:  matrixcruiser <matrixcruiser>
Submitted on:  Tue 18 Dec 2007 01:12:45 AM UTC  
 
Category: merge algorithmSeverity: 3 - Normal
Item Group: feature requestStatus: Invalid
Privacy: PublicAssigned to: Erik MT <codehappy>
Open/Closed: Closed
mtn version --full: 

monotone 0.38 (base revision: c1757f6cde49bddd77c82580059105bc470145b2)
windows native build

Mon 13 Oct 2008 09:34:26 AM UTC, comment #1:

Please read the monotone manual, section "Merging" and the documentation for the merge2 and merge3 hooks. They allow you to select a custom merger per file type.

Ludovic Brenta <lbrenta>
Project Member
Tue 18 Dec 2007 01:12:45 AM UTC, original submission:

Summarization of feature requests:
(detailed description follows in bottom part of this message:

1) Manual merge should be managed by merge ACTION.
I think, it is not good approach (logic & design) to join manual merge enforcement to "file & revision" couple using file attribute.
Plus: manual merge enforcement should be addressable to desired files during merge action.

2) Selection of appropriate merge tool should be file TYPE specific.

--------------------------------

Detailed description:

1)
Manual merge enforcement is currently implemented using mtn:manual_merge attribute which is specific per "file & revision" couple.
Such relationship (enforcing manual merge and "file & revision" couple) is not good from logical and design point of view. Manual merge is logically independent to "file & revision" couple.

Enforcement of manual merge should be managed by merge ACTION (mtn merge, mtn explicit_merge, ...) using reserved command line switch - for example:
"mtn explicit_merge rev1 rev2 branch --manual-merge=file1 --manual_merge=file2"
or
"mtn explicit_merge rev1 rev2 branch --manual-merge-all"
or some other analogical useful variation.

2)
Central configuration should allow to pre-configure binding between desired merge tool and file type - e.g.: M$ Word of OpenOffice for .doc files, AltovaXMLSpy for .xml *.html files, ...)

Approach of merge tool versus file type binding is very similar to approach used Rational ClearCase. It is proven by time, number of users and by big projects.

For example, well known binary files (like .so, .dll, .lib, .o(bj), ...) should be pre-configured to use some merge tool which allows to select left or right revision to make pure copy to resulting revision.

Unrecognized file types (unknown suffixes) should be evaluated for binary content in runtime (during merge action) and handled exactly like well known pure binary files.
Perhaps, sometime in future, there could be introduced special command line switch to select desired merge tool for desired file in current merge action.

Regards,
m3x

matrixcruiser <matrixcruiser>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by lbrenta (Posted a comment)
  • -unavailable- added by matrixcruiser (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 13 Oct 2008 09:34:26 AM UTClbrentaStatusNone=>Invalid
      Open/ClosedOpen=>Closed
      SummaryInappropriate logic & design of manual merge enforcement=>[Fixed in 0.20] Inappropriate logic & design of manual merge enforcement
    Thu 29 May 2008 05:30:41 AM UTCmatrixcruiserAssigned toNone=>codehappy

    Back to the top


    Powered by Savane 3.1-cleanup1