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.
