iffy behaviour with SVN external and "svn up -r"

Hi --

We in Apache SpamAssassin have run into what appears to be a bit
of an SVN externals misfeature.

We have our main trunk at
https://svn.apache.org/repos/asf/spamassassin/trunk , which contains
'rulesrc', an external for
https://svn.apache.org/repos/asf/spamassassin/rules/trunk . (We use this
as an external, since the rules therein can apply to multiple branches of
the code in asf/spamassassin/trunk.)

Both are in the same SVN repository -- just at different paths.

Here are the issues we've just noticed:

---------------------------------------------------------------------------

SVN UPDATE:

Let's say I want to pin down the checkout to a specific revision using
"svn update -r":

: exit=1 Wed Mar 1 09:34:11 GMT 2006; cd /home/jm/ftp/spamassassin
n : jm 35...; svn up -r 381595
D build/buildbot/bbmass_master.cfg
D build/buildbot/etc-init.d-buildbot
D build/buildbot/procmailrc
D build/buildbot/home-bbmass-dotcorpus
U build/mkupdates/tick_zone_serial
U lib/Mail/SpamAssassin/Message.pm
U lib/Mail/SpamAssassin/Util/RegistrarBoundaries.pm
U rules/active.list
U spamassassin.spec
U t/recursion.t
U t/mimeparse.t

Fetching external item into 'rulesrc'
D rulesrc/lang/es
U rulesrc/sandbox/duncf/20_drugs.cf
Updated external to revision 381965.

Updated to revision 381595.

Note how the main directory is correctly brought to r381595, but the svn
external in 'rulesrc' winds up at r381965 instead!

However if I issue an explicit "svn up -r" for that dir, it fixes it:

: exit=0 Wed Mar 1 09:34:59 GMT 2006; cd /home/jm/ftp/spamassassin
: jm 36...; svn up -r 381595 rulesrc
U rulesrc/sandbox/duncf/20_drugs.cf
Updated to revision 381595.

I can understand that it may be tricky to implicitly perform the "svn update
-r" on the external, too, since that may be coming from a different repository.
But I would suggest that it could either:

- (a) detect when the same repository is in use, and automatically use the -r
  functionality for both the main repo and the external

- or (b) warn more prominently that this is the case, since I've been failing
  to notice this behaviour for roughly 3 months now :( The "Updated external
  to revision 381965." message is pretty unobtrusive; to be honest, I
  assumed it had made a best effort to align to the "nearest" rev or
  similar.

---------------------------------------------------------------------------

SVN EXPORT:

An alternative to "svn update" is to export a copy of the repository
at a specific revision using "svn export -r":

: jm 46...; svn export --non-interactive -r 381955 http://svn.apache.org/repos/asf/spamassassin/trunk out
A out
A out/ldap
...
A out/spamd/README
A out/sample-nonspam.txt
A out/TRADEMARK

Fetching external item into 'out/rulesrc'
A out/rulesrc
A out/rulesrc/lang
A out/rulesrc/lang/pt_br
A out/rulesrc/lang/pt_br/30_text_pt_br.cf
....
A out/rulesrc/sandbox/felicity/70_other.cf
A out/rulesrc/sandbox/old
A out/rulesrc/sandbox/old/70_testing.cf
Exported external at revision 381973.

Exported revision 381955.

Note those last lines! The external has been exported -- but not at the
requested revision.

By performing a follow-up "svn export" it can be fixed:

: jm 49...; rm -rf out/rulesrc; svn export --non-interactive -r 381955 http://svn.apache.org/repos/asf/spamassassin/rules/trunk out/rulesrc
A out/rulesrc
A out/rulesrc/lang
A out/rulesrc/lang/pt_br
...
A out/rulesrc/sandbox/felicity/70_other.cf
A out/rulesrc/sandbox/old
A out/rulesrc/sandbox/old/70_testing.cf
Exported revision 381955.

In other words, explicitly running a separate "svn export" works around
it.

Again, more warning -- or implicit fixing -- or both -- would really help
here. What do you think?

Cheers for SVN! Loving it apart from that ;)

--j.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 1 13:03:31 2006