Homer, Marek is working on the Merger. He could probably answer some of these questions.
On Wed, 2006-12-06 at 14:54 +0800, Homer Simpson wrote: > Hey Kristis, > > Yes, very much so. I just checked out the description of the feature > enhancement and this would probably solve a lot of requirements for > management. > > Okay I just read through the comments and from what I understand, you > are selectively choosing which bugs to implement into the next > release. A question I have is that the changes you make for each bug, > where are they going to be stored? Is there another folder besides: > > trunk > tags > branch > > e.g. > > > trunk > tags > branch > bugs/002 > bugs/003 > bugs/004 Good question. The user would also supply the target branch name. So you could apply: --bug-list=2,3,4 into --base-branch="trunk" and --target-branch="branch/b_all_those_bugs_applied". The user can specify what he wants the final branch to be named (in this case "branch/b_all_those_bugs_applied"). > Also, how are conflicts going to be issued? Since you can ultimately > delay inserting a bug, for lets say 10 release builds, then the base > files that you initially used to start working on a bug might not be > usable...? (Sorry if my question isn't too clear, I'll try to think of > a situation)... No, it's a good point. You would have to produce the diffs between --base-branch and your bug, and then attempt to apply them. If there are conflicts (so some "patch --dry-run p0 < produced_diffs.patch" command fails) this will "have to be handled". Perhaps leave the diffs around for the user to manually inspect and resolve. In any case, the process would have to stop and the user must manually help. Marek perhaps has been thinking this some more. > My actual real life name is Homer Sampson (changed it officially) so > don't think I didn't provide my real name! > > Homer > > > > On 12/6/06, Kristis Makris <[EMAIL PROTECTED]> wrote: > On Wed, 2006-12-06 at 14:37 +1030, David O'Shea wrote: > > Of course, nowadays I would think that attaching the diffs > isn't the "right" thing to do and that you should go to the > version control system (via a link) to see the diffs. I guess > that since CVS doesn't do atomic commits, you can't easily see > ALL the diffs at once, which is probably a nice thing to be > able to do, but with Subversion I suppose you can? > > The current work on > http://bugzilla.mkgnu.net/show_bug.cgi?id=545 > introduces a new integration activity that given a bug id, or > list of > bug ids, it will fetch the list of affected files and their > revisions. > It would be possible to use the data provided by this activity > to then > query the SCM system to reproduce the diffs. > > Marek is working on a merge tool that can essentially apply > the diffs. > Perhaps getting a hold of the diffs is just a matter of > providing an > extra argument in this tool that will produce the diffs but > not apply > them. > > "Homer", if your goal is to be able to easily reproduce those > diffs, > would this merge tool be of help ? > > > _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
