Message-ID: <41E4BAF3.2020000@arbash-meinel.com>
Date: Tue, 11 Jan 2005 23:51:47 -0600
From: John Arbash Meinel <john@arbash-meinel.com>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: Robert Anderson <RWA@sbcglobal.net>
Subject: Re: [Gnu-arch-users] branch accounting/status tool
References: <AA-1B2242436106219C5AE4A79970BD4CD0-ZZ@www7.prodigy.net>
In-Reply-To: <AA-1B2242436106219C5AE4A79970BD4CD0-ZZ@www7.prodigy.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: gnu-arch-users@gnu.org
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 3232
Lines: 85
Robert Anderson wrote:

>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:
>
>  
>
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).

>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.
>  
>
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.

>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
>  
>
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.

John
=:->


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/