incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <...@apache.org>
Subject Re: Correct SVN practices (was Re: Fix for bug 119161)
Date Tue, 05 Jun 2012 04:08:52 GMT
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 <mayongl@apache.org> ha scritto:

> Da: Yong Lin Ma <mayongl@apache.org>
> Oggetto: Re: Correct SVN practices (was Re: Fix for bug 119161)
> A: ooo-dev@incubator.apache.org, pfg@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 <pfg@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.
> >
> 

Mime
View raw message