Re: [MAT-devel] bzr overview

[Jiri B. <ji...@ba...>]

Hello,

Juan:
> >> a central repository would alleviate this by exposing the repository.
> >> Jiri please correct me in this last point if this is not the case.

Jiri:
> > Somebody would have to run the central repository.

Juan:
> Why don't we keep the Bazaar central repository in Sourceforge. To avoid
> changing to many things at the same time, baby steps I guess. 

I guess that would be possible; actually, bzr does have provision for having a 
central, shared repository.

However, one the main points of switching to bzr is the move away from a 
central repository; having one anyway gives up some of the advantages... For 
instance, we still need to decide who has write access to it and who doesn't.

On the top level, as a project, we aren't actually centralised; there is no 
formal "Mat PLC" organisation that would be running the project. We are a 
collection of individuals. As it is, we're getting SourceForge to fill some 
of that management role, but it doesn't work very well - they fill the role 
of manager, but they are really a service. On many issues, they simply 
delegate back to us with no real tools to actually make those decisions.

Now, bzr wouldn't solve all of those issues; but it would solve those that 
pertain to access to the central repository - by eliminating it.

> The other advantage is that it will be easy to know where to get the central
> files for the project. Other advantage is that it will feel right for the
> new comers, remember appearances are important.

Yes, those are an advantage; we'll have to be careful to make that clear on 
the webpage.

> As I wrote the last paragraph I was thinking about the workflow needed
> to work on the project code with Bazaar as opposed to what we do in CVS.
...
> With Bazaar the commits will be to our local repository so we need an
> extra step that will be merge our branch with central repository. 

Actually, extra steps to merge the other developers' branches into our own.

> Of course this does not need to be done frequently and commit to a local
> copy has also advantages over committing to a central repository, easier
> to test code without disrupting the central repository code (this
> feature I have actually requested before).

Yes. In fact, you'd probably have several local copies - one following the 
main developments, one for porting hmi_gtk to gtk2, and so on. Others would 
probably follow several of those (on their own separate branches).

> > * Publishing your changes:

> > Put the entire directory up on the web and send the URL to the mailing
> > list (or to one of the developers, if you prefer). Don't forget to
> > "commit" first.  

> If we opt to keep the repository in sourceforge we will need to copy all
> the files (or is it possible to rsync them?) to sourceforge every time
> we wish the central repository to be updated.

* bzr has a mechanism for keeping a central repository, if that's what we want

* otherwise, rsync, as you suggest

> All this is besides the new requirement that each developer must publish
> its branch via a web page for example. Don't take me wrong, I like to
> try new things specially when they offer interesting features but I
> don't like complicated procedures because this is going to affect the
> project.

Well, the intent was that the branches on the developers' web pages would be 
the *only* way code gets passed around. That would be *instead* of a central 
repository rather than in addition to it.

> >> Before changing why don't we do a test drive. 
...
> > OK, here's one:
> > http://www.baum.com.au/~jiri/mat/test/

> Thanks, I will try to checkout this later.

("bzr branch", I assume; it won't let you "bzr checkout", because you don't 
have write access to my repository...)

Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/~jiri