= Notes/Subversion/Importing = == Importing RCS files to a repository == STILL WORKING ON THIS PAGE === Initial Import === Just importing the miriad tree as it stands is unsatisfactory, because we lose the revision history. So we use {{{cvs2svn}}}. '''Note:''' there is a [http://cvs2svn.tigris.org/issues/buglist.cgi?target_milestone=---&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&issue_status=RESOLVED&issue_status=VERIFIED&issue_status=CLOSED&field0-0-0=longdesc&type0-0-0=substring&value0-0-0=file%20already%20exists&field0-0-1=short_desc&type0-0-1=substring&value0-0-1=file%20already%20exists&field0-0-2=status_whiteboard&type0-0-2=substring&value0-0-2=file%20already%20exists bug] in the version of {{{cvs2svn}}} available in the Debian ''sarge'' release that causes the import to die partway through. The version available in Debian ''etch'' works correctly. The initial import goes like this (all three methods give the same result): {{{ % mkdir miriad % rsync -av /nfs/atapplic/miriad/ miriad/ # method 1 # we'll create a new repository in a directory named 'svnmiriad' % cvs2svn -s svnmiriad miriad # method 2 # we can create an empty repository named 'svnmiriad' and load via a dumpfile % cvs2svn --dumpfile=20071123.svndump miriad % svnadmin create svnmiriad % svnadmin load svnmiriad < 20071123.svndump # method 3 # add to an existing repository % svnadmin create svnmiriad % cvs2svn --existing-repos -s svnmiriad miriad }}} Not everything in the {{{miriad}}} directory gets imported (e.g. the binaries), because they have no RCS file. It's unclear how to do later imports, if we need to. Perhaps we would have to do something like this: {{{ % mkdir miriad2 % rsync -a /nfs/atapplic/miriad/ miriad2/ # create a new repos % cvs2svn -s svnmiriad2 miriad2 # assuming a repository named 'svnmiriad' % svn merge -rM:N svnmiriad2 svnmiriad #??? # M and N are revision numbers in the svnmiriad2 repository. }}} Another option is to treat the RCS version as a [http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html vendor] [http://lookfirst.com/2007/11/subversion-vendor-branches-howto.html branch]. === The Next Steps === tag the raw import, before we start to muck around with it. need to remove the compiled binaries No - the binaries never get checked into RCS so they aren't imported to svn. need to check out the code (and svn add all the files?) No - just do the cvs2svn dump. That does the "checkout" but it leaves the source files in the '.rcs' directory. We will need to move it from there. The import process creates two top-level directories; darwin_ppc, darwin_x86. These contain just a short GNUmakedefs file. Diffing them against the version in {{{scripts/darwin_*}}} indicates they are cruft and can be removed. check for things that should have been in RCS and weren't. This reveals some files with {{{,x}}} as their RCS suffix instead of the default {{{,v}}}. The {{{,x}}} files are ones that were no longer needed, but their history was retained. So just rename them and include in the import process; then svn remove them. {{{etc/archive}}} is not (all) in RCS. not sure what is needed here. {{{linpack}}} is all upstream code, does not need to be in the repo. {{{config}}} not sure what is needed here. {{{at_friends}}} apparently is obsolete and could be ignored. {{{linux, linux64, sun4sol, unicos}}} platform-specific directories aren't there but the {{{darwin_}}} ones are. check the programs are the same at the current revision. need to change the chkout, chklog targets currently if you want to do some work on miriad code, the [ftp://ftp.atnf.csiro.au/pub/software/miriad/INSTALL.html#devel programmer guidelines] say you make your own copy (very similar to a svn checkout) with: {{{ % /nfs/atapplic/miriad/scripts/mirtree % cd miriad }}} Note that you don't get '''all''' the code checked out, just the bits you want to change and not until you specify what you want. So to update {{{uvsplit}}}, for example: {{{ % cd prog % make uvsplit co RCS/GNUmakefile,v GNUmakefile RCS/GNUmakefile,v --> GNUmakefile revision 1.10 done Updating dependencies for /nfs/atapplic/miriad/prog/uvsplit.for /nfs/atapplic/miriad/linux/bin/ratty -b -s linux -I . -I /data/BEDLAM_1/mci156/svn/mt/miriad/inc -I /nfs/atapplic/miriad/prog -I /nfs/atapplic/miriad/inc /nfs/atapplic/miriad/prog/uvsplit.for /data/BEDLAM_1/mci156/svn/mt/miriad/linux/bin/uvsplit.f Number of lines = 1180; number of routines = 13 /usr/local/gnu/bin/g77-3.2.3 -g -ff90-intrinsics-hide -Wimplicit -Wunused -o /data/BEDLAM_1/mci156/svn/mt/miriad/linux/bin/uvsplit /data/BEDLAM_1/mci156/svn/mt/miriad/linux/bin/uvsplit.f /nfs/atapplic/miriad/linux/lib/libmir.a /nfs/atapplic/miriad/linux/lib/librpfits.a -L/nfs/atapplic/miriad/linux/lib -llinpack -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11 -lm % ls ../linux/bin total 256 216 uvsplit* 40 uvsplit.f }}} need to add handlers of .svn directories The GNUmakedefs defines a 'MIRFTP' variable; the comment about solaris-only is wrong. == Managing a vendor branch == [http://lookfirst.com/2007/11/subversion-vendor-branches-howto.html reference] This is an example script of how I do an upgrade from version 5.5.0 to 5.5.7. This assums that 5.5.0 has already been added using steps similar to below. 1. wget http://domain/jive_software_5.5.7.zip 2. unzip jive_software_5.5.7.zip 3. svn co -N http://svn/vendor/jivesoftware jivesoftware 4. mv jive_software_5.5.7 jivesoftware 5. cd jivesoftware 6. svn add jive_software_5.5.7 7. svn ci -m 'adding a clean download of 5.5.7' Now, the whole concept of the upgrade can be imagined with this simple statement: "I would like to take the difference between version 5.5.0 and 5.5.7 and apply that to what is in my development environment". In order to accomplish this, I check out my development tree locally and then execute a merge of the diff of the two versions. 1. svn co http://svn/dev/jive jive-dev 2. cd jive-dev 3. svn merge --ignore-ancestry http://svn/vendor/jivesoftware/jive_software_5.5.0/ http://svn/vendor/jivesoftware/jive_software_5.5.7/ . 4. svn ci -m 'upgraded development environment to 5.5.7' Note: if there are any conflicting files, you will need to resolve those conflicts before checking in. However, as you can see, you can locally modify any of the jive software files and the diff process will take care of doing the merges for you. ---- [wiki:Notes Notes Home]