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

[Zack Brown]

On Fri, Oct 03, 2003 at 10:52:00AM -0700, Joshua Haberman wrote:
> 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?

Visual format, but UML is really a language for describing relationships -
which is what you're doing. UML is actually very powerful, and has many
interesting facets. You should check it out.

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

Perfect! Check out its UML mode.

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

No, but you'd be qualified to accept patches from people who could. ;-)

Be well,
Zack

> 
> Thanks for your comments.
> 
> Josh
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/

-- 
Zack Brown