On Fri, Dec 26, 2008 at 04:28:53PM -0500, Stephen Leake wrote: > Pavel Cahyna <pavel.cah...@matfyz.cz> writes: > >> On the other hand, 'pluck' is a somewhat dangerous command in the > >> first place. Can you give a high level description of why you are > >> using it? In particular, using it twice? > > > > Well, if you cherrypick a selected change from one branch to another and > > this change creates new file(s), it is likely that later you will need > > other changes/fixes to them so you will pluck again a changeset which > > patches those newly created file(s). > > This is normally handled by branches, and merging the _whole_ branch. > You are implying that there are other changes in the source branch > that you _don't_ want.
Sure, I said "cherrypick a selected change", implying that I don't want the others. > > So the general solution is to design your branches better, so pluck is > not necessary. This is not feasible as a general solution, because it would require knowing in advance all the conceivable future uses of the branching scheme at the time one commits a revision. I.e. it would require knowing in advance what changes will anybody ever want to merge separately from the others. Consider sources with a main (developement) branch and release branch(es). You don't want to merge the whole main branch to a release branch, ever. One just carefully selects bugfixes and minor new features from the main branch and applies them to a release branch. pluck would be the way to do it if it DTRT. I do not see how better one could design this branching scheme... BTW - does monotone itself have release branches? I.e. are bugfixes merged to a stable branch instead of requiring everybody to update to the fixed version of the development branch? > > If you don't have sufficient control over the branching policies, I > can see how pluck might be part of a useful workflow. > > > There are already two tests for the directory variant of the bug: > > pluck_directory_bug_1 and pluck_directory_bug_2. The first has a commit > > between the plucks so is closer to a realistic situation, while the second > > does not have any commits between just like the one I showed here. > > The current pluck implementation builds three rosters, does > a merge, computes a changeset from the 'from' revision to the merged, > and applies that changeset to the working tree. > > I don't understand why it doesn't just apply the 'from to to' > changeset to the current working directory, as the description of the > command implies. The description goes on to say using a merge allows > pluck to "intelligently handles renames, conflicts and so on"; this > case demonstrates otherwise :). Maybe it intelligently handles the case when a file common between the two branches is renamed in one of them before the pluck? > It would be interesting to test the none-merge approach and see if it > solves this current problem and those tests. > > Interestingly, the existing test "pluck_basics" demonstrates the same > conflict, but implies it is the correct/desired behavior. > > I suspect there isn't a way to make 'pluck' do what everyone wants of > it. I think that making it work like "cvs up -j" does would be an improvement, even if it proper rename tracking were lost in exchange. Pavel _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel