You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Vincent Lefevre <vi...@vinc17.net> on 2012/03/29 16:01:51 UTC
random order due to APR hash change (was: random sort of svn status
and svn diff)
On 2012-03-21 00:51:53 +0000, Philip Martin wrote:
> Sérgio Basto <se...@serjux.com> writes:
>
> > On Tue, 2012-03-20 at 19:23 -0500, Ryan Schmidt wrote:
> >> On Mar 20, 2012, at 19:17, Sérgio Basto wrote:
> >>
> >> > Hi, I am facing a problem
> >> > I do a svn diff | lsdiff
> >> > I got file in random order , also happens with svn status
> >>
> >> Correct, Subversion does not output these in a sorted order.
> >
> > but one month ago , svn diff have always same output , now it is
> > random , is a bug or regression.
>
> That's the result of a change in the APR hash table implementation.
> Subversion often uses "hash order" and in the past this was always the
> same for a given set of hash keys. The new APR implementation means
> that this order is no longer constant.
In Subversion 1.6.x under Debian, it also affects the properties order
in "svn dump": http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664867
I don't know about Subversion 1.7.x.
As I've said in my bug report:
----------------------------------------
After the upgrade to libapr1 1.4.6-1, the properties in the "svn dump"
output are now in a random order. I don't think their order is
specified, but IMHO, they should be in a consistent order to allow
conventional tools like diff, MD5 checking on a dump, rsync[*] and
so on to work nicely.
[*] rsync will still work, but obviously less efficiently.
----------------------------------------
I had to revert to the previous libapr1 version.
> > why the output shouldn't be sorted by name or something else ?
> > or why svn don't have a sort option this is insane .
>
> It could be done but nobody has done it yet, the APR change is only a
> few weeks old. Sorting may need to be optional as there is a cost to
> sorting that not everybody would want.
Is this cost noticeable (when done efficiently)?
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: random order due to APR hash change (was: random sort of svn
status and svn diff)
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2012-03-29 10:07:02 -0400, Mark Phippard wrote:
> There is an issue filed for this:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=4134
Thanks. I've updated the Debian bug information.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: random order due to APR hash change (was: random sort of svn
status and svn diff)
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Mar 29, 2012 at 10:01 AM, Vincent Lefevre
<vi...@vinc17.net> wrote:
>> That's the result of a change in the APR hash table implementation.
>> Subversion often uses "hash order" and in the past this was always the
>> same for a given set of hash keys. The new APR implementation means
>> that this order is no longer constant.
>
> In Subversion 1.6.x under Debian, it also affects the properties order
> in "svn dump": http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664867
> I don't know about Subversion 1.7.x.
>
> As I've said in my bug report:
>
> ----------------------------------------
>
> After the upgrade to libapr1 1.4.6-1, the properties in the "svn dump"
> output are now in a random order. I don't think their order is
> specified, but IMHO, they should be in a consistent order to allow
> conventional tools like diff, MD5 checking on a dump, rsync[*] and
> so on to work nicely.
There is an issue filed for this:
http://subversion.tigris.org/issues/show_bug.cgi?id=4134
--
Thanks
Mark Phippard
http://markphip.blogspot.com/