|
From: | John Arbash Meinel |
Subject: | Re: [Gnu-arch-users] branch accounting/status tool |
Date: | Tue, 11 Jan 2005 23:51:47 -0600 |
User-agent: | Mozilla Thunderbird 1.0 (Macintosh/20041206) |
Robert Anderson wrote:
This seems interesting, but honestly it seems like to be really useful, you need to cross archives somehow. Because many times what you care about is other people's work. I'm not really sure how to make it all work. Possibly just having a config file stating what archives to look it (maybe what branches to care about).I think a branch accounting tool that does the following would be useful: You specify a version, and it recursively goes through all of your archives, and finds all versions which were branched from it. For each branch, it figures out if:
If you are reporting conflicts, it would seem that you need to actually create temporary directories, and try to apply the patches, etc. So this tool would probably be pretty slow. I don't know if this matters for your usage.1) There are missing patches from the parent 2) There are un-merged patches in the child 3) In each case 1&2, if a star-merge will result in conflicts in either direction It would give a summary listing that looks something like this: proj--main--0 <- -> proj--user--0 (missing and unmerged patches, no conflicts) <C proj--user2--0 (unmerged patches which cause conflicts) C> proj--blah1--0 (missing patches which conflict) proj--fixit--0 (fully up-to-date branch) -> proj--fixit-a--0 <C proj--fixit-b--0 <- proj--whoops--0 etc. You can quibble about the presentation, but I think the basic idea is a good one.
I've been playing with some scripts for generating the hierarchy tree including showing merged patches, etc. I'm using graphviz to generate an image, but it really doesn't scale to a lot of patches very well. (lots being 100s). Right now it actually works by importing all the patch info into a database, and then querying it to build the tree. The database stuff wasn't too difficult, and it makes the rest pretty quick. Actually, when I was filling it out, I found that it was horribly slow to try and use tla to download each patch-log on it's own, because of all the round-trips. Anyway, if you do create a database, you could also keep track of what patches conflict, which could help the speed of the system. But that might just be an optimization to add later.I never really looked into sealed versions, but maybe that's the way to handle branches that you want to consider "closed," which would only get listed with an option. The ease with which branches can be made also carries with it significant responsibility in keeping them all straight, up-to-date, and dealing with potential conflicts sooner rather than later when it can get out of hand. Going through this manually is a real chore. A one-step command for "here is your branch hierarchy, here is the general status of what is up to date with what, and here are the places where you're already looking at conflicts, so you better get a handle on those right away" seems like a must-have. Bob
John =:->
[Prev in Thread] | Current Thread | [Next in Thread] |