Difference between revisions of "Svn practices"

From Apache OpenOffice Wiki
Jump to: navigation, search
Line 1: Line 1:
−
 
 
This page is still under review.
 
This page is still under review.
  
−
1) Read-only access. This is meant for people that
+
This page gathered svn practices frequently used by contributors and committers. If you have any advice to this page, please feel free to update it or post your idea in ooo-dev mail list.
−
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:
+
== Read-only access ==
 +
 
 +
Grab the whole source code
 +
 
 +
Grab a branche
 +
 
 +
Update your tree
 +
 
 +
Update to a specific revision
 +
 
 +
Check changes in specific revision
 +
 
 +
 
 +
== Write access ==
 +
There is a guide for new committers:
 
http://www.apache.org/dev/new-committers-guide.html
 
http://www.apache.org/dev/new-committers-guide.html
  
−
But I actually think that a quick guide that explains
+
Commit your changes
−
how to set the default properties and how to do the
+
−
simple tasks would be great. My tips here are
+
  
−
I highly recommend:
+
Check changes before commit
  
−
1) specifying in the command line a list of the
+
Specify in the command line a list of the files/dirs that are changed to avoid accidentally committing unwanted changes.
−
files/dirs that are changed to avoid accidentally
+
 
−
committing unwanted changes.
+
Template for the log files should be used
  
−
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
 
svn commit ci -F ../mychangelog.txt change1 change2
  
−
3) Remind people to add the revision information
+
Do not use 'svn commit -m "Your comment".  
−
in Bugzilla for crossreference, if it applies.
+
  
−
This chapter should also explain how to create
+
Update bugzilla with revision information for crossreference when you are done with the commit
−
branches for bigger tasks and how to merge
+
 
−
changes to a branch.
+
How to create a branche of your own. When it comes to big or complicated changes, you may don't want to commit in stable branch directly.  
 +
 
 +
How to merge your changes
  
 
For reference, FreeBSD has a SVN Primer,
 
For reference, FreeBSD has a SVN Primer,
 
and the Merging section has some complete
 
and the Merging section has some complete
−
instructions:
 
−
http://wiki.freebsd.org/SubversionPrimer/Merging
 
  
−
Of course FreeBSD is more complex in structure
+
== Reference ==
−
and has many more committers so some additional
+
−
rules are in place:
+
  
−
In general we don't commit things directly
+
Merge Instruction from FreeBSD:
−
to the branches unless we have to and in that
+
http://wiki.freebsd.org/SubversionPrimer/Merging
−
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.
+

Revision as of 06:27, 5 June 2012

This page is still under review.

This page gathered svn practices frequently used by contributors and committers. If you have any advice to this page, please feel free to update it or post your idea in ooo-dev mail list.


Read-only access

Grab the whole source code

Grab a branche

Update your tree

Update to a specific revision

Check changes in specific revision


Write access

There is a guide for new committers: http://www.apache.org/dev/new-committers-guide.html

Commit your changes

Check changes before commit

Specify in the command line a list of the files/dirs that are changed to avoid accidentally committing unwanted changes.

Template for the log files should be used

svn commit ci -F ../mychangelog.txt change1 change2

Do not use 'svn commit -m "Your comment".

Update bugzilla with revision information for crossreference when you are done with the commit

How to create a branche of your own. When it comes to big or complicated changes, you may don't want to commit in stable branch directly.

How to merge your changes

For reference, FreeBSD has a SVN Primer, and the Merging section has some complete

Reference

Merge Instruction from FreeBSD: http://wiki.freebsd.org/SubversionPrimer/Merging

Retrieved from "https://wiki.openoffice.org/w/index.php?title=Svn_practices&oldid=201763"
Personal tools