[tex-live] svn vs. p4

[Reinhard Kotucha]

>>>>> "Gerben" == Gerben Wierda <Gerben.Wierda at rna.nl> writes:

  > This argument certainly does not count for me. I keep TeX alive
  > for older systems and my main system is as old as possible because
  > newer systems are generally downward compatible.

I suppose that Staszek has the same problems when he prepares binaries
which run with an ancient libc.

But do you need version control on these machines?  Suppose you have
the svn repository on your fastest machine and then copy the program
source tree and the texmf tree to the slow machine.  texmf-dist and
texmf-doc are not needed for compiling programs.  You can use 'svn
export' to extract a subtree, this tree will be clean, i.e. it will
not contain any .svn dirs.  If you are using NFS this is quite
convenient.

Before you change any files on the slow machine, create an empty file
somewhere (touch /tmp/tlsrc-timestamp). 

If you want to commit any changes, you can copy changed files back to
the repository on the fast machine:

  find /path/to/srcdir -newer /tmp/tlsrc-timestamp -exec cp ...

Then you can commit changed files from the fast machine.

If you want to test your binaries with real tex/latex files and macro
packages, you need texmf-dist as well.  But since you are testing
binaries, there is no need to update system-independent stuff at all.

I would not export the current texmf-dist from the repository to an
ancient machine.  It is sufficient to steal the much smaller
texmf-dist tree from teTeX or even install TL-2005 from the CD with
all the packages you don't need deselected in the install menu.

  >> 3. It is possible to overcome some problems by writing some
  >> scripts.  I just started to write one which runs svn info to
  >> determine the revision number of the local repository and then
  >> scans svnlog.  Some improvements still have to be done to make it
  >> useful.

  > [...]. If you can make 3 work, we are one step further IMO.

You can try:

    http://ms25.ath.cx/svnupdate

There is no manpage, please look into the source code.

There are two problems with this program:

  1. svnupdate creates a shell script ~/svncleanup which can be used
     to run 'svn cleanup' on the files or dirs updated by svnupdate.
     However, 'svn cleanup' requires a directory as an argument but
     not a file.  I'll fix this soon.

  2. When I press Control-C when the script is running, I'm not able
     to quit the script.  It seems that I quit a child process of it
     (subversion) instead.  I have no idea why this happens.  Maybe
     someone can enlighten me.

If you want to test svnupdate, you can replace 'BASE' (line 45) 

  open LOG, "svn log -vq -rBASE:HEAD $ENV{'TEXLIVE_SVN_ROOT'} |";

by an ancient revision number.  Subversion then thinks that the local
repository is at the revision number you inserted.  Karl started with
revision 1001.

The $dirlevel variable can be used to optimize performance.  It
determines how many slashes are needed within a path until svnupdate
updates complete directories instead of single files.

I fear that I cannot tell you an optimum value for this variable.  It
seems that, though I can update the whole tree faster than Staszek or
Werner, I need much more time to update a single file than they do.

When I run svnupdate in strace I have the impression that it takes a
considerable amount of time to connect to the server.  Don't know
why.  I don't have a nameserver on my machine, maybe this matters.

Also, the changes Karl made are not representative.  Many files had
been changed which are close to the root (READMEs, log files,...), but
when TL development starts more files near the leafs of the tree will
change.  Hence everybody has to tweak $dirlevel himself after TL
development started.

Staszek and Werner, how much time do you need to upgrade from revision
1001 to the current one using svnupdate?

Staszek, I still don't know why svn update sometimes gets the kill
signal and sometimes not.  To be able to exclude any problems with
your hardware, can you run memtest over night?

     http://www.memtest.org/

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha			              Phone: +49-511-4592165
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------