My solution so far has been to use bzr locally. It has a plugin which allows it to do integration with svn quite well, so I make a local branch here which is bound to the svn trunk, make branches off that, and I can easily make patches against it as needed. It works quite well.
I don't know what your experience with distributed SCM is. I'd encourage you to try it extensively before switching the repo to SVK, if you have not already. For some time I worked for Divmod, which followed a strict rule of doing all development in branches. It's described more (along with some others things not relevant to the point) at <http://divmod.org/trac/wiki/UltimateQualityDevelopmentSystem>. It's a very nice model, and some justifications are given in that document. It seems to be that the best course of action at present is to leave things as they are. I could configure something to email patches of work in progress to the list, but other than that, I'm happy with bzr, and you are happy with svn. However, if you do decide to switch to a distributed system, do consider some systems other than SVK. I think it's relation to SVN is a selling point to people already using SVN, but there are other systems that can migrate from SVN just as well which may offer other advantages. I'm using bzr here obviously. I know niklas has used git, and I've read it can integrate with svn also, although I've never tried doing that so I can't say how it works. On Fri, Sep 21, 2007 at 02:52:00PM +0200, Tim Blechmann wrote: > hi all, > > since a few people expressed their interest in contributing to nova, i > am currently thinking about a good way how to incorporate changes into > the subversion trunk, which can be considered as "my" branch ... > > at the moment, mischan expressed his interest in writing a numberbox > object, and niklas (with phil?) are trying to write a message object ... > first of all, i am really grateful, that you guys are interested in > helping with nova ... > > so, i am thinking of a way to be able to follow your work, while still > having the control over the trunk... > so, what i was thinking about, was to give write access to personal > branches on the svn, that you guys can work on ... something > like /branches/niklas_phil (if you guys want to work together?) > and /branches/mischan. > > pro: > - i can see what you are working on, mainly through the svn-commit > emails, so it will be easier for me to review your code, and it improves > the process of including patches to the trunk. > - i keep the full control over the nova trunk (at least for now) ... as > i don't know, how much time you are going to spent on nova, i feel > responsible to understand most of the code, so that i will be able to > maintain it on my own ... > > contra: > - you guys would work on a fork from the trunk, so you may miss bug > fixes or features that are introduced to the trunk. a decentralized > version control system may solve this problem, but it would make it > harder for me to follow, what you are working on ... tools like svk > would make it easier for you guys ... > > so i would somehow be in favor of the approach, giving you access to > branches. if you would like to work with personal svk repositories, it > would be great, if you can send emails to the nova-svn list with diffs > to the trunk every once in a while ... > > i will also try to write a document about the code style and formatting > of nova ... there _is_ a style, that i want the code to look like, but > unfortunately, i am not consistent with that myself, yet (there is still > some old code, which is written in the old style) > > i hope, this all sounds reasonable, it is just, that my main interest is > the code quality ... if anyone wants to get write access > to /branches/my_personal_branch, please contact me privately, including > a public gpg key, that i can use to send you an encrypted email > containing the password. > > cheers, tim > > -- > [EMAIL PROTECTED] ICQ: 96771783 > http://tim.klingt.org > > The price an artist pays for doing what he wants is that he has to do > it. > William S. Burroughs _______________________________________________ nova-dev mailing list [email protected] http://klingt.org/cgi-bin/mailman/listinfo/nova-dev http://tim.klingt.org/nova
