jm@jmason.org (Justin Mason) writes:
> 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:
I added a note to http://subversion.tigris.org/issues/show_bug.cgi?id=2209,
whose solution may be related to the problems you saw. Just FYI...
The behavior you saw is expected, but not desirable. Externals work
like separate updates/checkouts: they use HEAD by default unless the
external's specification has a "-rREVNUM". However, when they're
coming from the same repository, I think the behavior you expected
makes sense.
-Karl
> ---------------------------------------------------------------------------
>
> 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
>
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 3 00:37:28 2006