|
From: | Markus Schiltknecht |
Subject: | Re: [Monotone-devel] Re: How will policy branches work? |
Date: | Thu, 07 Feb 2008 08:16:28 +0100 |
User-agent: | Mozilla-Thunderbird 2.0.0.9 (X11/20080109) |
Hi, Nuno Lucas wrote:
What's the problem with that? It is an independent library so any other changes in other files have no relation with the changes we made in that directory (or other restricted path).
No problem with that. I just don't agree that partly unmerged revisions are a good thing to have.
The use-case is to "propagate" from that experimental branch just the added features you had implemented. I would expect something like "mtn propagate branch.testing branch.trunk "libs/*" would be enough.
I see, good example.
Offcourse there are a lot of different ways to accomplish the some thing, but it can be easier to the user if something so natural as that could be done.
Yeah, first of, I'm thinking about 'mtn pluck'. But that doesn't track merges...
By the way, I don't see as this is any different than what is already done by a 3-way merge with user editings. It's not the original revision either.
Well, the difference is, with a 3-way merge, you are saying: my newly merged revision X is the successor of A and B - in all files.
Here, you would need something like: revision X is the successor of A and B only for files in "libs/*". For files outside that restriction, there shouldn't be any preference (i.e. could still be A or B).
This is what I would call a partly unmerged revision. And what brings up lots of nasty problems: what should a checkout of revision X look like? Or shall it only allow further merges? Only allow updates from uncommon ancestors of A and B to the files in "libs/*"? A commit from within such a checkout would naturally end up in yet another partly merged revision.
I'm rather thinking, that changes to such modules should be committed separately, anyway. Thus, they can separately be merged by the people who know how to merge them. Those who don't shouldn't be forced to do the merge, yes. They don't have to. But they also shouldn't be forced to cope with partly merged revisions.
Regards Markus
[Prev in Thread] | Current Thread | [Next in Thread] |