Re: [Gnu-arch-users] new introduction to Arch with diagrams

[Joshua Haberman]

On Fri, 2003-10-03 at 07:03, Zack Brown wrote:
> On Thu, Oct 02, 2003 at 11:54:19PM -0700, Joshua Haberman wrote:
> > A picture is worth more than a thousands words when you're talking about
> > revision control where there are branches and changesets flying every
> > which way.
> > 
> > I have begun working on a succinct introduction to Arch's basic model
> > that makes liberal use of diagrams.  I would like feedback, especially
> > if any of it is false or misleading.  I am still quite new to Arch, and
> > there's a lot I still don't understand.
> > 
> > http://www.reverberate.org/computers/arch/model.html
> > 
> > Right now it covers the basics of branches, archives, changesets,
> > replay, and update.  As I learn more about merging between multiple
> > branches I will add this information also.
> 
> Looks very useful. Have you considered using UML for the diagrams? This
> has the advantage of not creating Yet Another Diagramming Format, and UML
> has solved a lot of problems you might encounter if your diagrams get much
> more complex.

I know almost nothing about UML.  I was under the impression it was just
a convention for drawing object hierarchies and such.  When you say
"format" do you mean file format or visual format?

> There are also programs like 'dia', which are able to draw
> UML diagrams quickly.

I am already using dia -- all the diagrams on that page were created
using it.

> I like the idea of adding diagrams to cover different ways of merging,
> like star-merge and prism-merge. If you do end up diagram those complex
> merge techniques, it would be great to have a diagram for each variation
> on those themes. My understanding is that things like star-merge are
> useful in a variety of different situations.

Yes, that is definitely a goal.  One reason I began this project was
because my understanding of the more complicated merges is very fuzzy. 
I hope to eventually create a very clear picture of when/why more
complicated merges are necessary, and how exactly they differ from
update/replay.

> Finally, you might also diagram work patterns, corresponding to the
> different ways of organizing an open source project. Most projects have
> some subtleties that represent specific problems arch needs to solve in
> order to work in that environment.

For the moment I'm only interested in development models as they
directly pertain to Arch's operation.  Furthermore, I don't think I
would be qualified to address subtleties in other projects' work
patterns.

Thanks for your comments.

Josh