From: Juan C. O. <jor...@ac...> - 2006-11-21 03:09:07
|
Jiri Baum wrote: > 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. > > OK. I see your point it is just a different way of hosting the project files. In any case it will always be easy to setup a centralized repository in case down the road we realized that we did need it. In a way we will be keeping backups of each other work and progress history. >> 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. > Yep. > >> 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. > OK. > >>>> 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...) > OK. My branch is now: http://www.acelab.com/mat/test I have to admit It was fairly easy to update, of course this is just one file but is enough to get the feeling of what it takes to use this new procedure of working with the files. Regards, Juan Carlos Orozco ACELAB Automation http://www.acelab.com |