You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Justin Mason <jm...@jmason.org> on 2006/03/01 12:00:55 UTC
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
Re: iffy behaviour with SVN external and "svn up -r"
Posted by Justin Mason <jm...@jmason.org>.
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
Re: iffy behaviour with SVN external and "svn up -r"
Posted by kf...@collab.net.
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
>
>
--
Re: iffy behaviour with SVN external and "svn up -r"
Posted by Kenneth Porter <sh...@sewingwitch.com>.
On Wednesday, March 01, 2006 12:00 PM +0000 Justin Mason <jm...@jmason.org>
wrote:
> 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.
Did you raise this on one of the Subversion mailing lists?
Perhaps the external property takes a versioned URI? In which case you'd
need to update the property if you wanted the property to track the parent
directory's version and not stay anchored to the tip.
Re: iffy behaviour with SVN external and "svn up -r"
Posted by Doc Schneider <ma...@maddoc.net>.
Justin Mason wrote:
> Hi --
[nipped]
>
> Cheers for SVN! Loving it apart from that ;)
>
> --j.
Jason,
Is apache.org running the latest v1.3.0 of SVN? I haven't installed it
here yet but am thinking on doing so.
--
-Doc
SA/SARE/URIBL/SURBL -- Ninja
4:56pm up 39 days, 14:16, 16 users, load average: 0.82, 0.61, 0.52
SARE HQ http://www.rulesemporium.com/
Re: iffy behaviour with SVN external and "svn up -r"
Posted by kf...@collab.net.
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