I hope this gets through to the list. If it does not please feel free to foward it.
On Sun, 2006-02-12 at 23:54 +0000, John Levon wrote: > On Mon, Feb 13, 2006 at 11:35:25AM +1300, Glynn Foster wrote: > > > O14. Per-file histories > > Yes. bzr meets E5, and also implements per-file histories. (changes to a > > file result in a link between that file and the changing revision, so > > one can report from the files history by looking up the changing > > revisions.) > > I'm not sure if that really answers O14 (so I'm not clear if bzr does manage > it > or not). O14 is talking about situations like this: > > a.c contains changes for bug 300 > b.c contains changes for bug 300 and bug 400 > c.c contains changes for bug 400 What are a.c, b.c, c.c here? Are they files or changes or ??? > Typically with repo-wide changeset model as opposed to file-specific > changesets, there's no way to commit these changes (given the requirement that > each individual bugfix must cannot be split across multiple commits) such > that: > > a.c contains a revision entry for bug 300 > b.c contains a revision entry for bugs 300 and 400 > c.c contains a revision entry for bug 400 > > People tend to like the file-based method as the revision entry for an > individual file only shows relevant bug IDs but also lets you commit lots of > bugs at once. To turn this into a use case, I understand you to be saying you want to do the following: * alter three files A, B and C such that A and B contain fixes for bug 300, and B and C contain fixes for bug 400. * Perform a single commit 'X' that records the changes to all the files. * Only see 'bug 300' when you look at the changes related to A in revision X, and vice verca, when looking at the changes in revision X see that A and B are involved in bug 300, but not C. Is that correct? > This falls out naturally of the file-based method of Teamware, but isn't a > very > good fit for SCMs using a repo-wide changeset model. It seems to me that the file based method will not really be meeting the 'only one commit' constraint to do this, but not having used Teamware ... I'd love to be walked through the UI to achieve this. I dont see any reason bzr cannot do it [although we definately do not support this precise usage in a built in manner today]. One way of doing it (not necessarily the best, just the 'I want it now approach') is a via a plugin. This plugin would gather your mapping of bug fixes<->files and record in the commit the following properties: bug300: 'A, B' bug400: 'B, C' (or B:'bug300, bug400' but either way should be fine) and decorate 'log' to accept a '--bug-number' option, and (finally) add a custom log formatter to work with that bug-number option to only show the relevant details. > To achieve the same effect for such an SCM, you'd have to split the operations > up into two commits: one for a.c and b.c containing only changes for bug 300, > and one for b.c and c.c containing only changes for bug 400. I dont see any reason to split up the commits to achieve what I [now :)] understand your requirement to be. > So can you clarify whether bzr can do O14 as I describe above? It wasn't clear > to me from your comment. I had misunderstood your requirement 014. But we can it easily without changing the data structure or code of bzr as sketched out above. If you'd like to work through your precise desired use cases - how you did this with Teamware - I'd be delighted to see if we can integrate this sort of functionality deeper into bzr for other users to use. It seems like it would be a very cool feature to have [if done tastefully :)]. Cheers, Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ tools-discuss mailing list [email protected]
