Subversion Notes: Difference between revisions
(3 intermediate revisions by the same user not shown) | |||
Line 287: | Line 287: | ||
... output from commit ... | ... output from commit ... | ||
[root@dev20-64 repo]# | [root@dev20-64 repo]# | ||
Method for a svn user: '''svnuser''' setup: (Note: substitute the name "'''user'''" with your Subversion user name. | |||
export SVNROOT="svn+ssh://user@svn.code.sf.net/p/nst/code"; | |||
alias svnuser='svn --username user'; | |||
svnuser update; svnuser merge ${SVNROOT}/dev/36 | |||
svnuser -m commit "Merging dev 36 area into repo 36 through r13374"; | |||
This is the old method used for merging and updating the '''Trunk Area''' with code changes in the '''Development 18 Area''' spanning from revision: "''''4869'''" to the "'''HEAD (4877)'''" (latest changes committed to the ''dev/18'' area). Use the following link for NST code revision reference: http://nst.svn.sourceforge.net/viewvc/nst | This is the old method used for merging and updating the '''Trunk Area''' with code changes in the '''Development 18 Area''' spanning from revision: "''''4869'''" to the "'''HEAD (4877)'''" (latest changes committed to the ''dev/18'' area). Use the following link for NST code revision reference: http://nst.svn.sourceforge.net/viewvc/nst | ||
Line 424: | Line 431: | ||
[root@vortex dev]# | [root@vortex dev]# | ||
[root@vortex dev]# svn --username USERID relocate http://svn.code.sf.net/p/nst/code svn+ssh://USERID@svn.code.sf.net/p/nst/code; | [root@vortex dev]# svn --username USERID relocate http://svn.code.sf.net/p/nst/code svn+ssh://USERID@svn.code.sf.net/p/nst/code; | ||
== Switching User Repository Root == | |||
Use this subversion method to switch the "'''Repository Root'''" user from "'''USERID1'''" to "'''USERID2'''": | |||
svn relocate svn+ssh://USERID1@svn.code.sf.net/p/nst/code/dev/38 svn+ssh://USERID2@svn.code.sf.net/p/nst/code/dev/38; | |||
= New NST Release Setup = | = New NST Release Setup = |
Latest revision as of 20:38, 24 April 2023
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
export SVNROOT=svn+ssh://user@svn.code.sf.net/p/nst/code
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 dev/FCVer (E.g., dev/30) as the current working area (this is what most developers will be checking out from and committing to). The following is the top level directory structure for Development (/dev), Release (/releases) and the pristine repository for pushing out package updates (/repo):
[nst@vortex ~]$ svn ls ${SVNROOT}/ dev/ releases/ repo/
Under each top level directory there are Fedora specific source trees:
[nst@vortex ~]$ svn ls ${SVNROOT}/dev 18/ 2.11.0/ 2.12.0/ 2.13.0/ 2.15.0/ 2.16.0/ 20/ 21/ 22/ 24/ 26/ 28/ 30/ 32/
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
To revert back to a previous revision use the merge option. The follow example reverts back to the 3986 revision from the 3987 revision for file: "bwmonitor.js". After the revert changes are applied you will need to commit. Use the Subversion Browser to assit in finding your revision numbers.
svn merge -r 3987:3986 bwmonitor.js
Revert Commit, Undo Commit, Reverse Merge
If you've committed modifications to a file accidentally it is a bit tricky to undo the commit. To get back an older version you need to perform something called a reverse merge. This is done by running the svn merge -r BAD:GOOD SOURCE command. Where BAD is typically the current revision ID of the source you want to revert, GOOD is the revision ID of the good code you want to restore and is typically 1 less than the value of BAD. SOURCE is typically the name of the file or directory you want to undo the commit on.
For example, we can used the following command to determine the last changed revision of the files under the current directory:
[pkb@refritos server]$ svn info . | grep Rev: Last Changed Rev: 10660 [pkb@refritos server]$
In this example the BAD revision ID is 10660 associated with the last commit done to this area. To restore the files to the 10659 state (the good version prior to the 10660) state, we would run the following command:
[pkb@refritos server]$ svn merge -r 10660:10659 . --- Reverse-merging r10660 into '.': U xrdp.cgi --- Recording mergeinfo for reverse merge of r10660 into '.': G . --- Eliding mergeinfo from '.': U . [pkb@refritos server]$
As the status command shows, this undo only impacted one file in the directory and is not immediately reflected in the repository.
[pkb@refritos server]$ svn status M xrdp.cgi [pkb@refritos server]$
This allows us to inspect the undone changes. If we are happy, we can commit this version back. If we are unhappy with the results, we can revert the state of the directory and try again.
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
Manage The Executable Flag On File
Use the following command to set the executable flag on a file (e.g., bwmonitor-ajax.php)under SVN control:
svn propset svn:executable bwmonitor-ajax.php
Use the following command to remove the executable flag on a file (e.g., bwmonitor-ajax.php)under SVN control:
svn propdel svn:executable bwmonitor-ajax.php
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 using the Subversion browser.
- 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 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 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 info Path: . URL: https://nst.svn.sourceforge.net/svnroot/nst/maintenance/2.13.0 Repository Root: https://nst.svn.sourceforge.net/svnroot/nst Repository UUID: c9574408-7c70-44fe-bb37-9fe24d5f8586 Revision: 2076 Node Kind: directory Schedule: normal Last Changed Author: pblankenbaker Last Changed Rev: 2076 Last Changed Date: 2011-05-10 16:53:57 -0400 (Tue, 10 May 2011) [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.
NOTE: After committing the changes, the maintenance/2.13.0/yum/pkgs/relaycheck revision number changed to 2103 (at the time of this writing) which is now larger than the original 2102 revision we used for the merge.
[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
Merging From Dev Area To The Repo Area
- Note: If this merge includes updates in the nstwui package: Have You Updated The NST WUI Release Number On The Dev Branch First?
The following demonstrates the current merge method to bring changes from the dev/20 development branch to the repo/20 area.
[root@dev20-64 ~]# cd repo [root@dev20-64 repo]# svn status -u # MAKE SURE YOU ARE COMMITTED AND UP TO DATE FIRST! [root@dev20-64 repo]# svn info Path: . Working Copy Root Path: /root/repo URL: https://svn.code.sf.net/p/nst/code/repo/20 Relative URL: ^/repo/20 Repository Root: https://svn.code.sf.net/p/nst/code Repository UUID: b5e161f0-cc72-4f2a-9017-da5bd5071a9c Revision: 6545 Node Kind: directory Schedule: normal Last Changed Author: rwhalb Last Changed Rev: 6545 Last Changed Date: 2015-02-14 08:44:42 -0500 (Sat, 14 Feb 2015) [root@dev20-64 repo]# svn update; svn merge https://svn.code.sf.net/p/nst/code/dev/20 . At revision 6594. --- Merging r6545 through r6594 into '.': U include/javascript/core/NstSelect.js U include/javascript/core/NstRuler.js ... U yum/pkgs/putty-win32 --- Recording mergeinfo for merge of r6545 through r6594 into '.': U . --- Recording mergeinfo for merge of r6545 through r6594 into 'yum/pkgs/putty-win32': G yum/pkgs/putty-win32 [root@dev20-64 repo]# svn commit -m "Merging up to 6545 from dev/20" ... output from commit ... [root@dev20-64 repo]#
Method for a svn user: svnuser setup: (Note: substitute the name "user" with your Subversion user name.
export SVNROOT="svn+ssh://user@svn.code.sf.net/p/nst/code"; alias svnuser='svn --username user'; svnuser update; svnuser merge ${SVNROOT}/dev/36 svnuser -m commit "Merging dev 36 area into repo 36 through r13374";
This is the old method used for merging and updating the Trunk Area with code changes in the Development 18 Area spanning from revision: "'4869" to the "HEAD (4877)" (latest changes committed to the dev/18 area). Use the following link for NST code revision reference: http://nst.svn.sourceforge.net/viewvc/nst
[root@dev16-32 repo]# svn status -u # MAKE SURE YOU ARE COMMITTED AND UP TO DATE FIRST! [root@dev16-32 repo]# svn proplist Properties on '.': svn:mergeinfo svn:ignore [root@dev16-32 repo]# svn propget svn:mergeinfo /dev:4409-4503,4516-4793 /dev/18:4795-4869 /maintenance/18:4794 /trunk:3591,3657-3699,3951,4042,4102-4106,4112,4145-4155,4196,4232-4240 [root@dev16-32 repo]# svn merge -r 4869:HEAD ${SVNROOT}/dev/18 . [root@dev16-32 repo]# svn propget svn:mergeinfo /dev:3590,3592-3611,3613-3614,3616,3618-3620,3622,3624-3627,3629-3702 [root@dev16-32 repo]# svn status -u ... shows files that were updated by the merge ... [root@dev16-32 repo]# svn commit -m "Merging up to 4877 from dev/18 - new release of the NST WUI" ... output from commit ... [root@dev16-32 repo]#
Merging From repo To dev Area
The easy method for merging the repo area changes into your dev area:
- Make sure all code is committed and everything is up to date.
- Set SVNROOT to point to the top level directory (like: https://svn.code.sf.net/p/nst/code).
- Run the merge command as shown below:
[pkb@chimi dev]$ svn merge $SVNROOT/repo/22 . --- Merging differences between repository URLs into '.': U include/dist/release-notes.txt U include/manifest/current.xml A include/manifest/release-22-7248.xml U include/data/configure.in U html/include/make/makefile U html/links.html U html/side.html U html/welcome.html U html/README.html U src/scripts/nstmenu/share/groups/release.group.xml U src/scripts/nstmenu/share/applications/release.apps.xml U yum/pkgs/nstmenu/template.spec U yum/pkgs/nstmenu/pkginfo.xml U yum/pkgs/nstweb/template.spec U yum/pkgs/nstweb/pkginfo.xml U . --- Recording mergeinfo for merge between repository URLs into '.': U . [pkb@chimi dev]$
The following demonstrates an older technique that merges the Development Area with code changes in the Repo Area spanning from revision: "'6534" to "'HEAD (6537)".
On repo:
[root@vortex repo]# svn propget svn:mergeinfo
/dev:4409-4503,4516-4793 /dev/18:4795-5411,5419-5496 /dev/20:5419-5501,5503-6533 /maintenance/18:4794 /trunk:3591,3657-3699,3951,4042,4102-4106,4112,4145-4155,4196,4232-4240
[root@vortex repo]#
On Dev:
[root@vortex dev]# svn status -u # MAKE SURE YOU ARE COMMITTED AND UP TO DATE FIRST! Status against revision: 6533 [root@vortex dev]# svn merge -r 6534:HEAD ${SVNROOT}/repo . [root@vortex dev]# svn propget svn:mergeinfo
/dev/18:5419-5496 /repo:4494,4505-4514,4516-4551,4555-4568,4586-4587,4614,4695,4717,4781,4812,5413-5415,5662-5666,6535-6537 /trunk:3591,3657-3699,3951,4042,4102-4106,4112,4145-4155,4196,4232-4240
[root@vortex dev]# svn status -u ... shows files that were updated by the merge ... [root@vortex dev]# svn commit -m "Merging up to 6537 from repo for new release" ... output from commit ... [root@vortex dev]#
Switching To A New Root
There can be many different branches of the same source tree at different levels of development within the Subversion repository. You can use the switch command to switch from one branch to another. When making a switch, the source code you have checked out will be updated to match the state of the source code in the new branch. Before making a switch, it is important to make sure that all of your changes are checked into the current branch. For example, the following demonstrates how to switch to the dev branch from the trunk branch:
[root@taco-dev32 repo]# svn info Path: . Working Copy Root Path: /root/repo URL: https://svn.code.sf.net/p/nst/code/repo Relative URL: ^/repo Repository Root: https://svn.code.sf.net/p/nst/code Repository UUID: b5e161f0-cc72-4f2a-9017-da5bd5071a9c Revision: 6540 Node Kind: directory Schedule: normal Last Changed Author: rwhalb Last Changed Rev: 6540 Last Changed Date: 2015-02-09 13:57:38 -0500 (Mon, 09 Feb 2015)
[root@taco-dev32 repo]# export SVNROOT="$(svn info | awk -- '$2 == "Root:" { print $3; }')"; [root@taco-dev32 repo]# echo $SVNROOT
https://svn.code.sf.net/p/nst/code
[root@taco-dev32 repo]# svn switch $SVNROOT/dev/20 At revision 3577. [root@taco-dev32 repo]#
After making a switch, you can use the info command to verify the switch was successful.
[root@taco-dev32 repo]# svn info Path: . URL: https://nst.svn.sourceforge.net/svnroot/nst/dev Repository Root: https://nst.svn.sourceforge.net/svnroot/nst Repository UUID: c9574408-7c70-44fe-bb37-9fe24d5f8586 Revision: 3577 Node Kind: directory Schedule: normal Last Changed Author: jdoe Last Changed Rev: 3577 Last Changed Date: 2012-05-29 10:04:54 -0400 (Tue, 29 May 2012) [root@taco-dev32 repo]#
Relocate To A New Repository Root
This section demonstrates switching repository root from one URL to another. In this example we switch from "http://svn.code.sf.net/p/nst/code" to "svn+ssh://USERID@svn.code.sf.net/p/nst/code". The svn "relocate" command is used.
[root@vortex dev]# svn info; Path: . Working Copy Root Path: /root/dev URL: http://svn.code.sf.net/p/nst/code/dev/26 Relative URL: ^/dev/26 Repository Root: http://svn.code.sf.net/p/nst/code Repository UUID: b5e161f0-cc72-4f2a-9017-da5bd5071a9c Revision: 9274 Node Kind: directory Schedule: normal Last Changed Author: user Last Changed Rev: 9274 Last Changed Date: 2017-10-11 16:07:51 -0400 (Wed, 11 Oct 2017) [root@vortex dev]# [root@vortex dev]# svn --username USERID relocate http://svn.code.sf.net/p/nst/code svn+ssh://USERID@svn.code.sf.net/p/nst/code;
Switching User Repository Root
Use this subversion method to switch the "Repository Root" user from "USERID1" to "USERID2":
svn relocate svn+ssh://USERID1@svn.code.sf.net/p/nst/code/dev/38 svn+ssh://USERID2@svn.code.sf.net/p/nst/code/dev/38;
New NST Release Setup
Currently the directory structure under Subversion is fairly straight forward. As an example we use dev/30 when working on Fedora 30 based builds. To move to Fedora 32 we do the following:
svn copy ${SVNROOT}/dev/30 ${SVNROOT}/dev/32;
When we are ready to push out a release we want to create our pristine repository area:
svn copy ${SVNROOT}/dev/32 ${SVNROOT}/repo/32;
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).