Context Navigation

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 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 vendor 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.

we should tag again, once we have rearranged the tree to our satisfaction.

need to change the chkout:, chklog: targets

not really. They are only defined if there is an RCS directory around (RCSDIR is defined) chklog: just prints what is going on as it calls chkout:. chkout: does the checkout.

we do however still need to distinguish (automatically) between "developer" and "system" builds.

currently if you want to do some work on miriad code, the 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
  % ls
  total 0
  0 RCS@
  % 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
  total 20
  20 GNUmakefile   0 RCS@
  % ls ../linux/bin
  total 256
  216 uvsplit*   40 uvsplit.f

The corollary to this is that the system is currently set up to build anything that is checked out, not just anything that was recently modified. So in "developer" mode we may be in the silly situation of having to delete the other programs so we can rebuild one of them (without the overhead of building everything). One way around this is if we could auto-collate a list of files with "M" status and just build those.

Working on the subversion checkout, this build process doesn't work; the makedefs are incorrect.

% pwd
/u/mci156/svn/svnmiriad/trunk/prog
% make uvsplit

Updating dependencies for uvsplit.for
/nfs/atapplic/miriad/linux/bin/ratty -b -s linux -I .  -I /u/mci156/svn/svnmiriad/trunk/prog/inc -I /nfs/atapplic/miriad/prog  -I /nfs/atapplic/miriad/inc uvsplit.for /u/mci156/svn/svnmiriad/trunk/prog/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 /u/mci156/svn/svnmiriad/trunk/prog/linux/bin/uvsplit /u/mci156/svn/svnmiriad/trunk/prog/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
make: /usr/local/gnu/bin/g77-3.2.3: Command not found
make: [/u/mci156/svn/svnmiriad/trunk/prog/linux/bin/uvsplit] Error 127 (ignored)
chmod: cannot access `/u/mci156/svn/svnmiriad/trunk/prog/linux/bin/uvsplit': No such file or directory
make: [/u/mci156/svn/svnmiriad/trunk/prog/linux/bin/uvsplit] Error 1 (ignored)

Edit linux/GNUmakedefs and then try again; that does not help
% pwd
/u/mci156/svn/svnmiriad/trunk/prog
% make show | grep g77
FC         = /usr/local/gnu/bin/g77-3.2.3

Perhaps I need to adjust MIRRC?

% pwd
/u/mci156/svn/svnmiriad/trunk/
% find . -name GNUmakefile -exec grep -l MIRRC {} \;
./GNUmakefile
% setenv MIR /u/mci156/svn/svnmiriad/trunk/
% make -n MIRRC
make: *** No rule to make target `MIRRC'.  Stop.

Part of the trick is to set $MIR correctly, but...

% make show
Variables defined in GNUmakedefs
================================

MIRROOT    = /u/mci156/svn/svnmiriad/trunk
MIRARCH    = linux

MIRDIR     = /u/mci156/svn/svnmiriad/trunk
THISDIR    = /umci156/svn/svnmiriad/trunk
MAKEMODE   = system

Preprocessors, compilers, etc. and their flags.
-----------------------------------------------
CO         = co
COFLAGS    = -f

RATTY      = /u/svn/svnmiriad/trunk/linux/bin/ratty
RATFLAGS   = -b -s linux

FC         = /usr/bin/g77
... etc ...

% cd prog
% make uvsplit
make: *** No rule to make target `uvsplit'.  Stop.
% make -d uvsplit
Updating makefiles....
 Considering target file `/u/mci156/svn/svnmiriad/trunk/linux/aux/prog.objlist'.
  File `/u/mci156/svn/svnmiriad/trunk/linux/aux/prog.objlist' does not exist.
  Looking for an implicit rule for `/u/mci156/svn/svnmiriad/trunk/linux/aux/prog.objlist'.
  No implicit rule found for `/u/mci156/svn/svnmiriad/trunk/linux/aux/prog.objlist'.
  Finished prerequisites of target file `/DATA/BEDLAM_1/mci156/svn/test3/workdir/svnmiriad/trunk/linux/aux/prog.objlist'.
 Must remake target `/u/mci156/svn/svnmiriad/trunk/linux/aux/prog.objlist'.
 Failed to remake target file `/u/mci156/svn/svnmiriad/trunk/linux/aux/prog.objlist'.

... it goes on...

Updating goal targets....
Considering target file `uvsplit'.
 File `uvsplit' does not exist.
 Looking for an implicit rule for `uvsplit'.
 No implicit rule found for `uvsplit'.
 Finished prerequisites of target file `uvsplit'.
Must remake target `uvsplit'.
make: *** No rule to make target `uvsplit'.  Stop.

consult the install doco again. I need to create MIRRC with some special magic and build everything. It's not obvious why there is no make MIRRC target at the top level.

% setenv MIR /u/mci156/svn/svnmiriad/trunk
% sed -e "s,@MIRROOT@,$MIR," scripts/MIRRC.in > MIRRC
% sed -e "s,@MIRROOT@,$MIR," scripts/MIRRC.sh.in > MIRRC.sh
% chmod 644 MIRRC*
% source MIRRC
% make
... screeds ensue ...
Buildhtmltask
make[1]: *** No rule to make target `/u/mci156/svn/svnmiriad/trunk/html/doc/detab.html', needed by `html'.  Stop.
make: [guides] Error 2 (ignored)

% svn status
?      MIRRC.sh
?      html
?      doc
?      MIRRC
?      guides/taskref.txt
?      specdoc/cheat.doc
?      specdoc/tasks.doc
?      linux/tmp
?      linux/lib
?      linux/bin
?      linux/man
?      linux/aux
M      linux/GNUmakedefs
?      prog/linux

need to add handlers of .svn directories

The GNUmakedefs defines a 'MIRFTP' variable; the comment about solaris-only is wrong.

Managing a vendor branch

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.

wget http://domain/jive_software_5.5.7.zip
unzip jive_software_5.5.7.zip
svn co -N http://svn/vendor/jivesoftware jivesoftware
mv jive_software_5.5.7 jivesoftware
cd jivesoftware
svn add jive_software_5.5.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.

svn co http://svn/dev/jive jive-dev
cd jive-dev
svn merge --ignore-ancestry http://svn/vendor/jivesoftware/jive_software_5.5.0/ http://svn/vendor/jivesoftware/jive_software_5.5.7/ .
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.

Notes Home

Last modified 16 years ago Last modified on 12/14/07 10:49:00

Download in other formats:

Plain Text