Excellent Yonh Lin Ma!! I wasn't expecting anyone would take the offer but I am glad you did.
We actually have some of the information here: http://incubator.apache.org/openofficeorg/developer-faqs.html but it doesn't have the best practices mentioned. I think we should have two different chapters: 1) Read-only access. This is meant for people that don't know that well what version control is but want to grab the code and play with it. It should contain how to do a checkout, update your tree, what the branches are and how to apply, revert or generate patches, It's actually a good practice to use svn diff to generate patches as it contains the information of the specific revision used to generate it. 2) Write access. There is a guide for new committers: http://www.apache.org/dev/new-committers-guide.html But I actually think that a quick guide that explains how to set the default properties and how to do the simple tasks would be great. My tips here are I highly recommend: 1) specifying in the command line a list of the files/dirs that are changed to avoid accidentally committing unwanted changes. 2) Use of a template for the log file with the author and other information. This is wrong: svn commit -m "My changes" This is right: svn commit ci -F ../mychangelog.txt change1 change2 3) Remind people to add the revision information in Bugzilla for crossreference, if it applies. This chapter should also explain how to create branches for bigger tasks and how to merge changes to a branch. For reference, FreeBSD has a SVN Primer, and the Merging section has some complete instructions: http://wiki.freebsd.org/SubversionPrimer/Merging Of course FreeBSD is more complex in structure and has many more committers so some additional rules are in place: In general we don't commit things directly to the branches unless we have to and in that case the Release Engineer has to approve the change. There's no such thing as lazy consensus there ;). We also set as minimum three days (I usually take a couple of weeks) before merging any change to the stable branch. Hope that helps, Pedro. --- Lun 4/6/12, Yong Lin Ma <mayo...@apache.org> ha scritto: > Da: Yong Lin Ma <mayo...@apache.org> > Oggetto: Re: Correct SVN practices (was Re: Fix for bug 119161) > A: ooo-dev@incubator.apache.org, p...@apache.org > Data: Lunedì 4 giugno 2012, 22:15 > Pedro, > I will do this. Please brief how do you hope the info will > be > organized and what should be highlighted. > > On Tue, Jun 5, 2012 at 12:16 AM, Pedro Giffuni <p...@apache.org> > wrote: > > > > --- Lun 4/6/12, Jürgen Schmidt ha scritto: > > > >> > > >> > I guess there's going to be no way to > convince > >> > people to use SVN correctly (hint: "svn > merge"). :( > >> > >> I simply haven't thought about it but I agree svn > merge > >> would have been better here. Especially when we > want to > >> merge the whole branch later to trunk to ensure > that > >> we have all fixes integrated. > >> > > > > svn merge actually helps a lot and I find it is really > > powerful, especially when there are big changes > involving > > creating or moving files. I think part of the problem > > is that we don't have the procedures documented yet > > and people are afraid to break something in the main > > tree. > > > > We do have a small primer but it can be improved. > > For new (and sometimes old) committers it's good > > to have some reference for doing their first commit, > > the first merge, creating their own feature branch, > > etc. > > > > Volunteers are welcome; I am a little busy but I > > can give some pointers if someone wants to take > > the task. > > > > Pedro. > > >
