Subversion Notes: Difference between revisions
(Added section describing how to use "svn merge" to get updates from the "trunk" area into the "maintenance/2.13.0" area) |
|||
Line 121: | Line 121: | ||
*.log | *.log | ||
tmp | tmp | ||
== Merging Changes Across Revisions == | |||
Our general strategy is typically to do all new work under the ''trunk'' area. However, when we move from one Fedora platform to another (like from Fedora 13 to Fedora 15), we will typically copy the ''trunk'' area to a sub-directory under the maintenance area. For example, the following shows the top level Subversion heirarchy (where you will see ''trunk'' and ''maintenance'') and the number of older maintenance areas where we have the ability to maintain older versions of the software. | |||
[root@f13-32 ~]# svn ls $SVNROOT | |||
maintenance/ | |||
releases/ | |||
trunk/ | |||
[root@f13-32 ~]# svn ls $SVNROOT/maintenance | |||
2.11.0/ | |||
2.12.0/ | |||
2.13.0/ | |||
[root@f13-32 ~]# | |||
In this situation, you may find yourself making changes to the ''trunk'' area that you would also like to apply to the ''2.13.0'' branch area. To accomplish this, use the following strategy: | |||
* Make your updates to the ''trunk'' area. | |||
* Commit your changes. | |||
* Determine the range of revision numbers for your change. The [https://sourceforge.net/apps/trac/nst/browser Subversion browser] feature provided by [https://sourceforge.net/apps/trac/nst/ Trac] makes this fairly easy. | |||
* Use the ''svn merge'' command to merge the changes into the ''maintenance/2.13.0'' area. | |||
Here is an example of using ''svn merge'' to merge the changes made for the 2.1.6 release of the relaycheck package from the ''trunk'' area to the ''maintenance/2.13.0'' area: | |||
* From looking at the [https://sourceforge.net/apps/trac/nst/browser/maintenance/2.13.0/yum/pkgs relaycheck revision number], I can see that the last revision number for the ''maintenance/2.13.0'' version was 2016 (at the time of this writing - it will change in the future). | |||
* From looking at the [https://sourceforge.net/apps/trac/nst/browser/trunk/yum/pkgs relaycheck revision number], I can see that the current revision number for the ''trunk'' version of relaycheck was 2102 (at the time this article was written). | |||
* At this point I have enough information to merge the changes with the following ''svn merge'' command: | |||
[root@f13-32 repo]# svn merge -r 2016:2102 $SVNROOT/trunk/yum/pkgs/relaycheck yum/pkgs/relaycheck | |||
--- Merging r2076 through r2102 into 'yum/pkgs/relaycheck': | |||
U yum/pkgs/relaycheck/src/relaycheck.pl | |||
U yum/pkgs/relaycheck/pkginfo.xml | |||
U yum/pkgs/relaycheck/relaycheck.template.spec | |||
[root@f13-32 repo]# svn status | |||
M yum/pkgs/relaycheck | |||
M yum/pkgs/relaycheck/src/relaycheck.pl | |||
M yum/pkgs/relaycheck/pkginfo.xml | |||
M yum/pkgs/relaycheck/relaycheck.template.spec | |||
[root@f13-32 repo]# | |||
At this point, we should make sure the merged changes still build and then commit our changes. | |||
[root@f13-32 repo]# cd yum | |||
[root@f13-32 yum]# make relaycheck | |||
... Omitted much of the output ... | |||
------------------------------------------------------------------------------- | |||
SUCCESS: Successfully installed relaycheck-1.2.6-11.nst13.noarch.rpm | |||
------------------------------------------------------------------------------- | |||
make[1]: Leaving directory `/root/repo/yum/pkgs/relaycheck' | |||
[root@f13-32 yum]# svn commit | |||
= Related Links = | = Related Links = |
Revision as of 07:46, 11 May 2011
We switched from using CVS to Subversion as our source control mechanism in mid October 2009.
- We did not try to import all of the CVS history.
- The initial import includes all of the 2.11.0 release source plus the updated source code since the release (the state of CVS on 2009-10-14).
- We left the CVS repository alone (in case we ever wanted to refer back for older history).
Preparing Development Machine
As a developer, the following things must be done to your development machine before you will be able to check out, build and commit changes to the NST source code.
Set SVNROOT
You need to set the SVNROOT variable. Add the following to your ~/.bashrc or ~/.bash_profile configuration file:
export SVNROOT=https://nst.svn.sourceforge.net/svnroot/nst
After the SVNROOT variable is set, you should be able to run Subversion commands. For example the following shows the directories under SVNROOT.
[pkb@sprint ~]$ export SVNROOT=https://nst.svn.sourceforge.net/svnroot/nst [pkb@sprint ~]$ svn ls ${SVNROOT} trunk/ [pkb@sprint ~]$
gnome-keyring
Subversion might complain about needing to store passwords in a unencrypted form. To prevent this, we need to figure out how to enable the gnome-keyring add-on. To do this, edit the file ~/.subversion/config and search on the string password-stores. Most likely this will be commented out in your current configuration file. I updated mine to the following:
password-stores = gnome-keyring
However, this was not enough to prevent me from being prompted each time. I then added the following package:
yum install subversion-gnome
We will see if this permits us to store the password or not (you may need to be logged into a GNOME desktop in order to make use of the gnome-keyring feature).
Directory Structure
Currently the directory structure under Subversion is fairly straight forward. We use trunk as the current working area (this is what most developers will be checking out from and committing to). When we have a release, we will copy trunk to the release number. For example, to create the 2.13.0 release, we would run the following Subversion command:
svn copy ${SVNROOT}/trunk ${SVNROOT}/releases/2.13.0
We would also run the following command for maintenance updates to the 2.13.0 release:
svn copy ${SVNROOT}/trunk ${SVNROOT}/maintenance/2.13.0
Subversion Commands
Use the following to get the list of available subversion commands:
svn help
To get more information about a specific Subversion command (like ls), run:
svn help ls
Checking Out Code
To make the initial checkout of the current source code into a sub-directory named nst, you can use the following Subversion command:
svn co ${SVNROOT}/trunk nst
Committing Code
You use the commit subversion command when you want to commit changes to the source code.
When you first run commit, it may prompt you for the password for the incorrect user ID. If this happens, press the Enter key without specifying a password. This should allow you enter your SourceForge user ID followed by your SourceForge password when committing changes. For example:
[root@fedora11 nightly]# svn commit Authentication realm: <https://nst.svn.sourceforge.net:443> SourceForge Subversion area Password for 'root': Authentication realm: <https://nst.svn.sourceforge.net:443> SourceForge Subversion area Username: SOURCEFORGE_LOGIN_ID Password for 'SOURCEFORGE_LOGIN_ID': Sending nightly/nightly-build.bash Sending nightly/nightly2html.xsl Sending nightly/nightly2txt.xsl Transmitting file data ...----------------------------------------------------------------------- ATTENTION! Your password for authentication realm: <https://nst.svn.sourceforge.net:443> SourceForge Subversion area can only be stored to disk unencrypted! You are advised to configure your system so that Subversion can store passwords encrypted, if possible. See the documentation for details. You can avoid future appearances of this warning by setting the value of the 'store-plaintext-passwords' option to either 'yes' or 'no' in '/root/.subversion/servers'. ----------------------------------------------------------------------- Store password unencrypted (yes/no)? no Committed revision 4. [root@fedora11 nightly]#
Status
The Subversion status command is very handy at showing not only what files you've modified, but also (when including the -u option) handy at showing what files have changed in the repository:
svn status -u
For help about the output of svn status, run:
svn help status | less
Revert
If you've made modifications to a file which you want to discard, use the revert command to restore the original version:
svn revert FILENAME
Ignoring Files
Under CVS, you could edit the file .cvsignore to tell CVS to ignore certain files within the directory. Subversion has a similar, but different mechanism for ignoring files. Basically, you change to the directory where the files/directories to be ignored exist and run the following command:
svn propedit svn:ignore .
Running the above command should pull up a text editor and allow you to specify file name patterns to specify what files and directories should be ignored. Here is an example ignore list which causes Subversion to ignore any file or directory ending with the extension .log or having the name tmp:
*.log tmp
Merging Changes Across Revisions
Our general strategy is typically to do all new work under the trunk area. However, when we move from one Fedora platform to another (like from Fedora 13 to Fedora 15), we will typically copy the trunk area to a sub-directory under the maintenance area. For example, the following shows the top level Subversion heirarchy (where you will see trunk and maintenance) and the number of older maintenance areas where we have the ability to maintain older versions of the software.
[root@f13-32 ~]# svn ls $SVNROOT maintenance/ releases/ trunk/ [root@f13-32 ~]# svn ls $SVNROOT/maintenance 2.11.0/ 2.12.0/ 2.13.0/ [root@f13-32 ~]#
In this situation, you may find yourself making changes to the trunk area that you would also like to apply to the 2.13.0 branch area. To accomplish this, use the following strategy:
- Make your updates to the trunk area.
- Commit your changes.
- Determine the range of revision numbers for your change. The Subversion browser feature provided by Trac makes this fairly easy.
- Use the svn merge command to merge the changes into the maintenance/2.13.0 area.
Here is an example of using svn merge to merge the changes made for the 2.1.6 release of the relaycheck package from the trunk area to the maintenance/2.13.0 area:
- From looking at the relaycheck revision number, I can see that the last revision number for the maintenance/2.13.0 version was 2016 (at the time of this writing - it will change in the future).
- From looking at the relaycheck revision number, I can see that the current revision number for the trunk version of relaycheck was 2102 (at the time this article was written).
- At this point I have enough information to merge the changes with the following svn merge command:
[root@f13-32 repo]# svn merge -r 2016:2102 $SVNROOT/trunk/yum/pkgs/relaycheck yum/pkgs/relaycheck --- Merging r2076 through r2102 into 'yum/pkgs/relaycheck': U yum/pkgs/relaycheck/src/relaycheck.pl U yum/pkgs/relaycheck/pkginfo.xml U yum/pkgs/relaycheck/relaycheck.template.spec [root@f13-32 repo]# svn status M yum/pkgs/relaycheck M yum/pkgs/relaycheck/src/relaycheck.pl M yum/pkgs/relaycheck/pkginfo.xml M yum/pkgs/relaycheck/relaycheck.template.spec [root@f13-32 repo]#
At this point, we should make sure the merged changes still build and then commit our changes.
[root@f13-32 repo]# cd yum [root@f13-32 yum]# make relaycheck ... Omitted much of the output ... ------------------------------------------------------------------------------- SUCCESS: Successfully installed relaycheck-1.2.6-11.nst13.noarch.rpm ------------------------------------------------------------------------------- make[1]: Leaving directory `/root/repo/yum/pkgs/relaycheck' [root@f13-32 yum]# svn commit
Related Links
- http://nst.svn.sourceforge.net/viewvc/nst
- Use this link to browse the NST Subversion repository (the 'trunk' folder corresponds to the current development tree).
- http://sourceforge.net/apps/trac/nst/
- Use this link to access the NST Trac Wiki (for development). It has its own source browser as well as tracking commits via the Timeline.