[tex-live] svn update killed

[Karl Berry]

    I meant to find what has last been committed, something similar to
    'p4 changes -l -m 3' just to see quickly if something has changed,
    and...  is worth to run 'svn update'

That p4 command shows files changed for the last 3 commits?  Well,
as stated, the answer to that is:
  svn log -vq -rHEAD  # note revision number in first line, say 1562
  svn log -vq -r1560:1561

It would obviously be trivial to write a script to automate that for any N.
(BTW, if you leave off the `q', you get the log msgs as well.)


As a perhaps more convenient alternative, it seems the following command
will show all the files that have changed between your last global svn
update and the repository, inclusive:
    svn log -vq -rBASE:HEAD

You can extract just the filenames with some more pipelining:
   | grep '^   [ADMR] ' | cut -c7- | sort -u

(The basic idea comes from http://subversion.tigris.org/faq.html#terse-diff.)

Then you can run  cd /your/svn/root && svn update  to get just those files.
(Where /your/svn/root is the dir with the trunk/, branches/, tags/ subdirs.)

However, I noticed two gotchas in this:

1) svn log reports information from BASE to HEAD *inclusive*.  So it
   will always output the files updated in your last update (BASE).
   I.e., the output of svn log -rBASE:HEAD will not be empty even after
   a global update.

2) When run on a specific set of files, svn update only updates those
   files, reasonably enough.  But svn log works by default on the root
   of your checked-out hierarchy.  Therefore it is necessary to run
svn update -N /your/svn/root
   after updating the files that were actually changed.  Otherwise, the
   next svn log -rBASE:HEAD will report the same set of files.


Bottom line: I believe you can do a "quick" update by running these
three commands:

svn log -vq -rBASE:HEAD |grep '^   [ADMR] ' |cut -c7- |sort -u >/tmp/changed
cd /your/svn/root && svn update `cat /tmp/changed`
svn update -N /your/svn/root

This could be put in a script and fixed up (to determine BASE+1) easily
enough, I imagine, but let's see if it actually solves your problem
first.  And if we're moving forward in general.


The real question is still why your global svn update takes 20 minutes
(although I know even 3 minutes would be a pain) ...


karl