On May 23, 2006, at 4:07 PM, Denis Andrejew wrote:
> > Hi MochiKit guys, > > I'm a quiet MochiKit user and mailing list reader for quite some > time now and I learned a lot from the discussions and > the architecture and use of MochiKit! Thanks for all the work you, > Bob, and the other developers and users put into > this! There are not many open source / web / whatever projects out > there which can actually teach you so much! > > I've got some questions regarding stuff not directly related to > MochiKit - but I saw a lot of questions like this > answered here so I'll give it a try ;) > > I downloaded and browsed the MochiKit SVN repository and I'm quite > impressed how clean everything is organised. I use > SVN in a mid-sized project and so far I'm the only coder on that > project and so I use not much more than only > Subversion's commit and revert functions. > But our company grows and in the next few weeks some people are to > join the developer group. > For me this means that I have to find some standard use patterns > for Subversion. I thought before reading through a pile > of SVN tutorials I could ask (and maybe discuss) here how to do > stuff with Subversion - as I said I noticed that you do > know how to use it well! > > If nobody is interested in answering those newb questions, I'd be > happy with a link to a good (and maybe short?) > tutorial that discusses what practical use of SVN looks like in mid- > sized to large projects with lots of developers > working on it. Pretty much all of these questions are sufficiently answered by the Subversion Book, which is available in print from O'Reilly or free online: http://svnbook.red-bean.com/ Some of the larger projects using Subversion may have project specific guidelines, but I'm not sure off the top of my head which projects these are. I'd probably look at Python, Apache, and Subversion itself to see if they have specific guidelines and what they are. > So the basic questions that I can think of atm are: > > * How to ensure that a single developer doesn't break the code for > all others? Use branches (that's what I read > somewhere one should do)? What is there to be aware of when using > branches? How to use them properly? For major changes we use a branch. Otherwise we just don't break stuff. If someone does end up breaking something on the trunk, it shows up in the tests and people start filing issues in the trac. This really doesn't happen much, and when it does happen it doesn't last very long. > * How to handle the code base for the next not-bugfix-version? > Branch trunk? Normally MochiKit has a single path of development, so we get the trunk into a release state and just tag it when it's ready. Some projects branch before release, in this case it's not particularly necessary. > * What are tags for and what's the difference between tags and > branches? Branches are a work in progress and tags are supposed to be some specific point in time. Neither has any special meaning to subversion; they're implemented the same way (by using copy). > * How are bugfixes to be handled when you've got a online > production version of the software and a development version > if both versions need the bugfix applied? I know one can create > patches from changes but what is the proper way to > create and apply them? Normally this is done with a maintenance branch for the stable version. Creating patches is usually done with svn diff, but depending on how different the development and stable versions are the fix might need to be "manually" applied. -bob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~----------~----~----~----~------~----~------~--~---
