--- Begin Message ---
I'm sorry, may have missed some points earlier that could answer my
questions:
-you specify all bugs form the trunk/branch that should be included in a
new build
Of course the tool should check for all cases if there is a version in the
history of updated files that is not included in the base label + list of
bugs and warn about it.
Homer
On 12/6/06, Homer Simpson <[EMAIL PROTECTED]> 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
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)...
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 ?
>
>
>
--- End Message ---
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
