kfogel@collab.net writes:
> 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.
Thanks! At least a clear warning message indicating the behaviour
would be helpful, imo.
cheers,
--j.
> -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 11:44:40 2006