You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by SteveKing <st...@gmx.ch> on 2004/09/06 17:12:19 UTC
request for backporting to 1.1.x
Hi,
Issue 2016 has been fixed in revisions 10788 and 10796. I'd really want
this backported to the 1.1.x branch, even if it's not activated in the
command line client. That would save me from merging those two revisions
every time I build TortoiseSVN, and if it's not activated in the command
line client it wouldn't even be used by it. So the "danger" of
backporting tends against null.
I haven't seen this mentioned in the STATUS file, so I would at least
request to put this there for voting.
Also, on a different subject: the crash in 'svn st -u' I reported for
the fourth time here:
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=228147
with a detailed description on how to fix it here:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=75574
hasn't been fixed yet, even though the fix would require only one
additional NULL-pointer check. May I ask for this to be fixed now and
analyzed why this could happen later? After all, this is a _crash_!
Also, when this gets fixed, I would request the backport to 1.1.x for
that too.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: request for backporting to 1.1.x
Posted by SteveKing <st...@gmx.ch>.
Greg Hudson wrote:
> But the translation code path is affected by r10788 whether or not the
> initialization function is called. It's just affected in different
> ways.
Ah, ok. I understand.
> Perhaps you don't understand; if we backport r10788 and don't call
> svn_utf_initialize() in the command-line client, it looks like we would
> experience significant performance degradation *relative to current 1.1
> levels*.
Ok. But the performance degradation of 1.1 to 1.0 is significant too. At
least on windows. And that should be fixed before 1.1 is released. At
least for TortoiseSVN which does an 'svn st' all the time when showing a
working copy in the explorer, this is a really serious issue! And not
just that: a commit of a lot of files now takes about ten times longer -
not the actual commit where the filedeltas are sent, but the time from
starting the commit until the filedeltas are sent. And during that time
the CPU is used 100% by the Subversion process.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: request for backporting to 1.1.x
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-09-06 at 15:16, Stefan wrote:
> > As it turns out, it looks like we might
> > experience significant performance degradation if we don't call
> > svn_utf_initialize().
> I thought not
> activating it would at least not endanger the command line client but
> still give TortoiseSVN the chance to use it.
But the translation code path is affected by r10788 whether or not the
initialization function is called. It's just affected in different
ways.
> And yes, the performance without caching the translation functions (keep
> the so files loaded and reuse them instead of loading/unloading them) is
> really, really bad.
Perhaps you don't understand; if we backport r10788 and don't call
svn_utf_initialize() in the command-line client, it looks like we would
experience significant performance degradation *relative to current 1.1
levels*.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: request for backporting to 1.1.x
Posted by Stefan <st...@tigris.org>.
Greg Hudson wrote:
> (Also, how did you imagine that r10788 would pose no risk to the client
> if we don't activate svn_utf_initialize()? How would
> svn_utf_initialize() do any good if we didn't change the code path of
> actual translation functions? As it turns out, it looks like we might
> experience significant performance degradation if we don't call
> svn_utf_initialize().)
I just thought that since it was mentioned in the issue. The comment
there said that a change this big would require another RC release
first, but since that's not likely going to happen I thought not
activating it would at least not endanger the command line client but
still give TortoiseSVN the chance to use it.
And yes, the performance without caching the translation functions (keep
the so files loaded and reuse them instead of loading/unloading them) is
really, really bad.
>>Also, on a different subject: the crash in 'svn st -u' I reported for
>>the fourth time here:
>
> I took the ten minutes to figure out what was going on here and checked
> in a fix (r10841). I'll nominate it for 1.1.
>
> Of course, it's also a big problem that we don't have enough safety
> checks in "svn switch --relocate".
Thanks for that!
(nagging works!)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: request for backporting to 1.1.x
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-09-06 at 13:12, SteveKing wrote:
> Hi,
>
> Issue 2016 has been fixed in revisions 10788 and 10796. I'd really want
> this backported to the 1.1.x branch, even if it's not activated in the
> command line client. That would save me from merging those two revisions
> every time I build TortoiseSVN, and if it's not activated in the command
> line client it wouldn't even be used by it. So the "danger" of
> backporting tends against null.
I found some substantial problems with r10788 in my review, so I can't
nominate it yet. But I agree that we must fix this problem before
releasing 1.1. It's dangerous to release a 1.x release with performance
or functionality regressions which might dissuade people from upgrading
from 1.(x-1).
(Also, how did you imagine that r10788 would pose no risk to the client
if we don't activate svn_utf_initialize()? How would
svn_utf_initialize() do any good if we didn't change the code path of
actual translation functions? As it turns out, it looks like we might
experience significant performance degradation if we don't call
svn_utf_initialize().)
> Also, on a different subject: the crash in 'svn st -u' I reported for
> the fourth time here:
I took the ten minutes to figure out what was going on here and checked
in a fix (r10841). I'll nominate it for 1.1.
Of course, it's also a big problem that we don't have enough safety
checks in "svn switch --relocate".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org