Re: [Fwd: Re: *** NOTICE: This mailing list is now CLOSED ***]

[C. Michael Pilato]

Ed wrote:
> Greg Stein wrote:
>> Subscribing is via: announce-subscr...@subversion.apache.org (woulda
>> been nice to include instructions in your email)
>>
>> To *post* to annou...@s.a.o, you (apparently) need to use your
>> @apache.org address, so it was immediately refusing his attempt to
>> subscribe.
> 
> Is this applicable to other mailing lists?  i.e. If you are not
> subscribed, you need to post with your @apache.org address otherwise
> it's revoked?Or is this only because announ...@s.a.o is
> a read-only mailing list (for regular users)?  (ditto with
> s...@s.a.o?)

This requirement is unique to the announce@ list (at least, across the
Subversion mailing list set).

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: [Fwd: Re: *** NOTICE: This mailing list is now CLOSED ***]

[Ed]

Greg Stein wrote:

Subscribing is via: announce-subscr...@subversion.apache.org (woulda
been nice to include instructions in your email)

To *post* to annou...@s.a.o, you (apparently) need to use your
@apache.org address, so it was immediately refusing his attempt to
subscribe.


Is this applicable to other mailing lists?  i.e. If you are not
subscribed, you need to post with your @apache.org address otherwise
it's revoked?Or is this only because announ...@s.a.o is
a read-only mailing list (for regular users)?  (ditto with
s...@s.a.o?)

Edmund

Re: A website for subversion.apache.org

[C. Michael Pilato]

Hyrum K. Wright wrote:
> We need a website at subversion.apache.org.  We've put up some
> placeholder pages, and I recently started playing with an
> Anakia-generated site in it's place.  I've come across a few questions,
> and they are thus:
> 
> * What information should be presented?
> * How should we present the information?
> * How do we glue the two together?
> 
> The first question is about content, the second about style, and third
> about how we should generate the site (manual editing, templating
> mechanism, etc.)  I've got some ideas about where to shift the content,
> but I've no eye for style at all.  As for the third point, I've spent
> some time playing with Anakia (as recommended by the Incubator), but it's
> kinda unwieldy.  In any case, I'm interested in what others think.

Let's do this backwards.

Regarding the site generation, I say don't.  We have (or should have) a
static header, a static footer, and a static left-nav.  Surely we can just
SSI those three bits into the right spot in an HTML template file that's
copied each time we need a new file.  I'm not terribly thrilled about having
to mess with some silly Java program just to generate HTML from almost-HTML.

Style is largely a matter of opinion.  Not sure I want to dive into the
larger bikeshed of fonts and colors right now.  But there are some style
matters that we should discuss because changing our minds later can come at
some cost.

First, we need to decide if we want a hierarchical URL space or a flat one;
if we want self-describing document basenames or if we don't care.  It's the
difference between /svn_1.6_releasenotes.html and /releases/notes/1.6.html
(or maybe /release-notes/1.6.html), if you need a practical example.

Another style matter is page length.  Some folks think monolithic documents
like our hacking.html are good because they reduce clicks.  Others
acknowledge that click reduction was a fine goal ... in 1998.

And as for navigation, I *don't* want to see a left-nav that's essentially a
site map (too big) or one as positively useless as the one on subversion.t.o
right now (too specialized).  Further, I'd prefer that the left-nav contain
no offsite links (and yes, that includes the current "ASF" link) -- put that
junk in the content of relevant pages where it can be described and not give
the impression of linking to a part of the site itself, or at least set it
off from the "main menu" (as an ad button or somesuch).

As for the content itself, I think we largely have the right kinds of stuff
in place today (on s.t.o).  I'd drop stale stuff like the Testimonials.  I'd
consider dropping the Links, too -- it's Google's world now.  I'd never put
anything like merge-tracking design docs in our public website again -- for
crying out loud, we can just point people to the repository URLs for those
things!

And I'd be sushi to get some spaghetti into th--  oh dear.  It appears I'm
too hungry to continue thinking about websites, and it's making me grumpy.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

Re: A website for subversion.apache.org

[Branko Čibej]

Mark Phippard wrote:
> On Fri, Jan 8, 2010 at 3:55 PM, Hyrum K. Wright
>  wrote:
>   
>> We need a website at subversion.apache.org.  We've put up some placeholder 
>> pages, and I recently
>> started playing with an Anakia-generated site in it's place.  I've come 
>> across a few questions, and they
>> are thus:
>>
>>  * What information should be presented?
>>  * How should we present the information?
>>  * How do we glue the two together?
>>
>> The first question is about content, the second about style, and third about 
>> how we should generate
>> the site (manual editing, templating mechanism, etc.)  I've got some ideas 
>> about where to shift the
>> content, but I've no eye for style at all.  As for the third point, I've 
>> spent some time playing with Anakia
>> (as recommended by the Incubator), but it's kinda unwieldy.  In any case, 
>> I'm interested in what others
>> think.
>> 
>
> I have not had to do a website like this in years as I've usually been
> doing Java web stuff or like what you have on hosting sites.  It is
> not clear to me why we need a generator though.  Most of the look and
> feel would just come from style sheets.  It seems like there must be
> something we can do either in the style sheets or with server-side
> includes or something to stick the standard navigation on each page.
> That seems like the only bit where a generator helps.
>   

I agree. Given that we won't have a huge site, we can afford to be a bit
careful with the content and leave it at that. Generators are evil. If
we really need something more complex than an editor, I'd prefer to use
a real CMS.

-- Brane

Re: Subversion in 2010

[Branko Čibej]

Greg Hudson wrote:
> On Fri, 2010-01-08 at 15:31 -0500, Paul Querna wrote:
>   
>> "Profile everything, be faster at everything"
>> 
>
> There are smart people who will disagree with me on this, but I'm not
> sure the best tool for improving Subversion performance is a profiler.
> Historically a lot of our performance issues have come from algorithmic
> inefficiencies, particularly from code in libsvn_repos.  You can get
> maybe a 10-30% reduction in time on these operations by trying to
> optimize the innermost bit of code which gets repeated over and over
> again, but in some cases you can get an order of magnitude reduction in
> time by fixing the algorithms.
>
> It's been too long for me to remember any specific examples,
> unfortunately.
>   


You'd be surprised. A long time ago I saw a profiler log that seemed to
indicate we were spending 90% of our time in the delta combiner. I
refused to believe what I saw and never looked closer. Then DannyB came
along and showed how a simple succession of target copy operations could
slow the delta combiner tremendously. That was a reality check with a
vengeance.

In my experience the trick is in reading profiler output correctly, and
actually analysing more than the last three levels of the call graph
before trying to optimize anything.

-- Brane

Re: Subversion Bug

[Johan Corveleyn]

You have bumped into a known issue [1], which is fixed in svn 1.6.6.
So upgrading to TortoiseSVN 1.6.6 should help.

[1] http://subversion.tigris.org/issues/show_bug.cgi?id=3485

Regards,
Johan

On Fri, Jan 8, 2010 at 8:22 PM, Razmik Shahinian
 wrote:
> in file
> TortoiseSVN-1.6.3\ext\subversion\libsvn_ra_svn\marshal.c
> line 486: assertion failed(opt||cstr)
>

Re: Subversion in 2010

[Paul Querna]

On Fri, Jan 8, 2010 at 12:54 PM, Greg Hudson  wrote:
> On Fri, 2010-01-08 at 15:31 -0500, Paul Querna wrote:
>> "Profile everything, be faster at everything"
>
> There are smart people who will disagree with me on this, but I'm not
> sure the best tool for improving Subversion performance is a profiler.

What i really mean by 'profile' is time everything, figure out where
`svn update` spends 4 seconds.  And yes, many times it will be an
algorithmic issue, but the first step is to just profile everything,
and figure out the biggest wins, some of them might surprise us.

> Historically a lot of our performance issues have come from algorithmic
> inefficiencies, particularly from code in libsvn_repos.  You can get
> maybe a 10-30% reduction in time on these operations by trying to
> optimize the innermost bit of code which gets repeated over and over
> again, but in some cases you can get an order of magnitude reduction in
> time by fixing the algorithms.
>
> It's been too long for me to remember any specific examples,
> unfortunately.
>
>
>

Re: A website for subversion.apache.org

[Mark Phippard]

On Fri, Jan 8, 2010 at 3:55 PM, Hyrum K. Wright
 wrote:
> We need a website at subversion.apache.org.  We've put up some placeholder 
> pages, and I recently
> started playing with an Anakia-generated site in it's place.  I've come 
> across a few questions, and they
> are thus:
>
>  * What information should be presented?
>  * How should we present the information?
>  * How do we glue the two together?
>
> The first question is about content, the second about style, and third about 
> how we should generate
> the site (manual editing, templating mechanism, etc.)  I've got some ideas 
> about where to shift the
> content, but I've no eye for style at all.  As for the third point, I've 
> spent some time playing with Anakia
> (as recommended by the Incubator), but it's kinda unwieldy.  In any case, I'm 
> interested in what others
> think.

I have not had to do a website like this in years as I've usually been
doing Java web stuff or like what you have on hosting sites.  It is
not clear to me why we need a generator though.  Most of the look and
feel would just come from style sheets.  It seems like there must be
something we can do either in the style sheets or with server-side
includes or something to stick the standard navigation on each page.
That seems like the only bit where a generator helps.

Back in November, I think, we tossed around some example sites that
looked good and worth copying.

http://felix.apache.org is one I remember that was nice and clean.
They generate their site from the wiki though and I do not think we
want to do that.  But we could still use their styles and just come up
with our own way to do the navigation stuff.

I think we had some of the same content discussions back then as well,
but I would like to see us spend a little more effort on user-facing
information.  A little evangelizing and features, where you get
binaries etc.  Of course all the stuff you are already putting up
there is needed to.  I take it as a given we will figure out the
developer parts we want without problem.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Subversion in 2010

[Joe Schaefer]

Warning: Paul Querna is a svn heretic.



- Original Message 
> From: Paul Querna 
> To: Hyrum K. Wright 
> Cc: Subversion Dev 
> Sent: Fri, January 8, 2010 3:31:51 PM
> Subject: Re: Subversion in 2010
> 
> On Fri, Jan 1, 2010 at 10:22 AM, Hyrum K. Wright
> wrote:
> > I hope the holidays have been good for everybody in the Subversion 
> > community. 
>  In between spending some quality time with family, and eating more than I 
> ought, I've done a bit thinking about Subversion in 2010, what I'd like to 
> see 
> happen, and some goals that we can work toward as a community.  Here's my 
> list 
> (in no particular order):
> >
> > * Release 1.7 with wc-ng and obliterate support
> >
> > * Build our developer community
> >
> > * Finish joining the ASF and dissolve SVN Corp
> >
> > * Talk to users more
> >
> > * Build out our web presence on s.a.o.
> >
> > * Profit! (well, maybe not...)
> >
> > Each of these probably deserves it's own thread for more in-depth 
> > discussion, 
> but it's useful to have a high-level view.  What are your plans for 
> Subversion 
> in 2010?
> 
> As brought up in the other replies, I think the stated goal of
> Subversion 1.8 should be something like:
> 
> "Profile everything, be faster at everything"
> 
> git has done this constantly, and we see the results, sure some of
> what they do is messy, but Apache projects in general have always
> taken the time to get architectures right, and do the execution of a
> design well.
> 
> Thanks,
> 
> Paul



  

A website for subversion.apache.org

[Hyrum K . Wright]

We need a website at subversion.apache.org.  We've put up some placeholder 
pages, and I recently started playing with an Anakia-generated site in it's 
place.  I've come across a few questions, and they are thus:

 * What information should be presented?
 * How should we present the information?
 * How do we glue the two together?

The first question is about content, the second about style, and third about 
how we should generate the site (manual editing, templating mechanism, etc.)  
I've got some ideas about where to shift the content, but I've no eye for style 
at all.  As for the third point, I've spent some time playing with Anakia (as 
recommended by the Incubator), but it's kinda unwieldy.  In any case, I'm 
interested in what others think.

-Hyrum

Re: Subversion in 2010

[Greg Hudson]

On Fri, 2010-01-08 at 15:31 -0500, Paul Querna wrote:
> "Profile everything, be faster at everything"

There are smart people who will disagree with me on this, but I'm not
sure the best tool for improving Subversion performance is a profiler.
Historically a lot of our performance issues have come from algorithmic
inefficiencies, particularly from code in libsvn_repos.  You can get
maybe a 10-30% reduction in time on these operations by trying to
optimize the innermost bit of code which gets repeated over and over
again, but in some cases you can get an order of magnitude reduction in
time by fixing the algorithms.

It's been too long for me to remember any specific examples,
unfortunately.

Re: Subversion in 2010

[Hyrum K. Wright]

On Jan 8, 2010, at 2:31 PM, Paul Querna wrote:

> On Fri, Jan 1, 2010 at 10:22 AM, Hyrum K. Wright
>  wrote:
>> I hope the holidays have been good for everybody in the Subversion 
>> community.  In between spending some quality time with family, and eating 
>> more than I ought, I've done a bit thinking about Subversion in 2010, what 
>> I'd like to see happen, and some goals that we can work toward as a 
>> community.  Here's my list (in no particular order):
>> 
>> * Release 1.7 with wc-ng and obliterate support
>> 
>> * Build our developer community
>> 
>> * Finish joining the ASF and dissolve SVN Corp
>> 
>> * Talk to users more
>> 
>> * Build out our web presence on s.a.o.
>> 
>> * Profit! (well, maybe not...)
>> 
>> Each of these probably deserves it's own thread for more in-depth 
>> discussion, but it's useful to have a high-level view.  What are your plans 
>> for Subversion in 2010?
> 
> As brought up in the other replies, I think the stated goal of
> Subversion 1.8 should be something like:
> 
> "Profile everything, be faster at everything"

That's a *great* suggestion.

> git has done this constantly, and we see the results, sure some of
> what they do is messy, but Apache projects in general have always
> taken the time to get architectures right, and do the execution of a
> design well.

I think really it's a question of resources.  I wish we had a small group (~3 
people) whose entire role was to do profiling and performance improvements.  
Another group for regressions and bug fixes.  Another for web stuff and doc 
tasks.  And then a somewhat larger group of folks focused on development.

This may sound like the antithesis of open source, but it sometimes feels to me 
like we're very under-resourced, and what resources we do have aren't focused.  
I don't know how to solve either problem, short of increased corporate 
involvement or a massive PR blitz in the open source community.

-Hyrum

Re: Subversion in 2010

[Paul Querna]

On Fri, Jan 1, 2010 at 10:22 AM, Hyrum K. Wright
 wrote:
> I hope the holidays have been good for everybody in the Subversion community. 
>  In between spending some quality time with family, and eating more than I 
> ought, I've done a bit thinking about Subversion in 2010, what I'd like to 
> see happen, and some goals that we can work toward as a community.  Here's my 
> list (in no particular order):
>
> * Release 1.7 with wc-ng and obliterate support
>
> * Build our developer community
>
> * Finish joining the ASF and dissolve SVN Corp
>
> * Talk to users more
>
> * Build out our web presence on s.a.o.
>
> * Profit! (well, maybe not...)
>
> Each of these probably deserves it's own thread for more in-depth discussion, 
> but it's useful to have a high-level view.  What are your plans for 
> Subversion in 2010?

As brought up in the other replies, I think the stated goal of
Subversion 1.8 should be something like:

"Profile everything, be faster at everything"

git has done this constantly, and we see the results, sure some of
what they do is messy, but Apache projects in general have always
taken the time to get architectures right, and do the execution of a
design well.

Thanks,

Paul

ASF: what do we have left?

[Hyrum K. Wright]

It's been a few weeks, since we've talked about it, and as our report to the 
Incubator PMC is due sometime soon, I'd like to ask: what do we have left for 
graduation?  I'm not trying to rush the process, just advance it.

-Hyrum

Re: [Fwd: Re: *** NOTICE: This mailing list is now CLOSED ***]

[Greg Stein]

Subscribing is via: announce-subscr...@subversion.apache.org (woulda
been nice to include instructions in your email)

To *post* to annou...@s.a.o, you (apparently) need to use your
@apache.org address, so it was immediately refusing his attempt to
subscribe.

Cheers,
-g

On Fri, Jan 8, 2010 at 14:48, C. Michael Pilato  wrote:
> Uh-ohs.
>
> --
> C. Michael Pilato 
> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
>
> Michael,
>
> Sending a 'subscribe' mail to  results in:
>
> 
> Hi. This is the qmail-send program at apache.org.
> I'm afraid I wasn't able to deliver your message to the following addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.
>
> :
> Must be sent from an @apache.org address.
> 
>
> What gives?
>
> Thanks,
>
> Sean
>
>
>
> On 1/8/10 1:43 PM, C. Michael Pilato said:
>
>>Dear Person Interested in Subversion Announcements:
>>
>>As part of the transition of the Subversion project into Apache-ness, we
>>will no longer be posting announcements to this list.  Instead, our
>>announcements will go to:
>>
>>   annou...@subversion.apache.org
>>
>>Please subscribe there if you haven't already and still wish to receive
>>notifications of Subversion-related events and releases and such.
>>
>>Thanks.
>>
>>--
>>C. Michael Pilato 
>>CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
>>
>>--
>>http://subversion.tigris.org/ds/viewMessage.do?
>>dsForumId=445&dsMessageId=2435829
>>
>>To unsubscribe from this discussion, e-mail: [announce-
>>unsubscr...@subversion.tigris.org].
>
>
>
>

Subversion Bug

[Razmik Shahinian]

in file
TortoiseSVN-1.6.3\ext\subversion\libsvn_ra_svn\marshal.c
line 486: assertion failed(opt||cstr)

[Fwd: Re: *** NOTICE: This mailing list is now CLOSED ***]

[C. Michael Pilato]

Uh-ohs.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
--- Begin Message ---
Michael,

Sending a 'subscribe' mail to  results in:


Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
Must be sent from an @apache.org address.


What gives?

Thanks,

Sean



On 1/8/10 1:43 PM, C. Michael Pilato said:

>Dear Person Interested in Subversion Announcements:
>
>As part of the transition of the Subversion project into Apache-ness, we
>will no longer be posting announcements to this list.  Instead, our
>announcements will go to:
>
>   annou...@subversion.apache.org
>
>Please subscribe there if you haven't already and still wish to receive
>notifications of Subversion-related events and releases and such.
>
>Thanks.
>
>--
>C. Michael Pilato 
>CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
>
>--
>http://subversion.tigris.org/ds/viewMessage.do?
>dsForumId=445&dsMessageId=2435829
>
>To unsubscribe from this discussion, e-mail: [announce-
>unsubscr...@subversion.tigris.org].


--- End Message ---


signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Make svn clients indicate their operation name to backend(right now only to DAV)

[Kamesh Jayachandran]

On 01/06/2010 09:09 PM, C. Michael Pilato wrote:

Philip Martin wrote:
   

Kamesh Jayachandran  writes:

 

This patch is with respect to the original thread

http://mail-archives.apache.org/mod_mbox/subversion-dev/201001.mbox/browser
   

This one I suppose:

http://mail-archives.apache.org/mod_mbox/subversion-dev/201001.mbox/<4b41f1bd.8090...@collab.net>

It includes:

"We can proxy this request to the Master but we *should not* do
 that if it is for read operation."
 

With all due respect, the proposed solution looks enormous compared to the
size of the problem.   Does the original problem exist in HTTPv2?  At a
minimum, could the ra_dav providers not annotate the PROPFIND as
"dont-proxy-this" without even touching the RA (and higher) APIs?

   


May be I can tweak 'svn_ra_neon__get_one_prop' which I believe the one 
that makes the problematic PROPFIND call.


Though the quantum of change would be relatively smaller than my 
original patch, I do *not* like it as it looks too secretive to set one 
custom flag deep inside the code for one special case.


My patch has the additional(tangential to its original intension) 
benefit of 'administrative control of activity based on operation names'.


With regards
Kamesh Jayachandran

Re: 1.6.8 Status

[Mark Phippard]

On Fri, Jan 8, 2010 at 10:39 AM, Stefan Sperling  wrote:
> On Fri, Jan 08, 2010 at 09:19:27AM -0600, Hyrum K. Wright wrote:
>>
>> On Jan 8, 2010, at 9:16 AM, Hyrum K. Wright wrote:
>>
>> > As a result of the various problems surrounding 1.6.7, we're pulling the 
>> > release, and will re-roll as 1.6.8.  The only blocker for rolling is the 
>> > r896522, r896547 which addresses a regression found in the 1.6.7 tarball 
>> > (and uncovered by the ruby bindings).  As soon as this fix is backported, 
>> > I'll roll 1.6.8.
>> >
>> > In the meantime, please revert the r896522, r896547 group, as well as any 
>> > other items which should be included in 1.6.8.
>>
>> That should be *review the r896522, r896547 group*, not "revert".
>
> I'll commit my +1 in a minute.
>
> Note that Paul added a new file resolve_tests.py to 1.6.x which has
> an Apache 2.0 license header. Should the license header be changed
> for backport?

No, we already distribute files with different licenses (even no
license) in them so I do not see where it would matter.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: 1.6.8 Status

[Hyrum K. Wright]

On Jan 8, 2010, at 9:39 AM, Stefan Sperling wrote:

> On Fri, Jan 08, 2010 at 09:19:27AM -0600, Hyrum K. Wright wrote:
>> 
>> On Jan 8, 2010, at 9:16 AM, Hyrum K. Wright wrote:
>> 
>>> As a result of the various problems surrounding 1.6.7, we're pulling the 
>>> release, and will re-roll as 1.6.8.  The only blocker for rolling is the 
>>> r896522, r896547 which addresses a regression found in the 1.6.7 tarball 
>>> (and uncovered by the ruby bindings).  As soon as this fix is backported, 
>>> I'll roll 1.6.8.
>>> 
>>> In the meantime, please revert the r896522, r896547 group, as well as any 
>>> other items which should be included in 1.6.8.
>> 
>> That should be *review the r896522, r896547 group*, not "revert".
> 
> I'll commit my +1 in a minute.
> 
> Note that Paul added a new file resolve_tests.py to 1.6.x which has
> an Apache 2.0 license header. Should the license header be changed
> for backport?

If the file is licensed under the ALv2, I suspect not.  (Though let's not 
devolve into some deep license discussion which hangs up the release for 3 
weeks.)

-Hyrum

Re: 1.6.8 Status

[Stefan Sperling]

On Fri, Jan 08, 2010 at 09:19:27AM -0600, Hyrum K. Wright wrote:
> 
> On Jan 8, 2010, at 9:16 AM, Hyrum K. Wright wrote:
> 
> > As a result of the various problems surrounding 1.6.7, we're pulling the 
> > release, and will re-roll as 1.6.8.  The only blocker for rolling is the 
> > r896522, r896547 which addresses a regression found in the 1.6.7 tarball 
> > (and uncovered by the ruby bindings).  As soon as this fix is backported, 
> > I'll roll 1.6.8.
> > 
> > In the meantime, please revert the r896522, r896547 group, as well as any 
> > other items which should be included in 1.6.8.
> 
> That should be *review the r896522, r896547 group*, not "revert".

I'll commit my +1 in a minute.

Note that Paul added a new file resolve_tests.py to 1.6.x which has
an Apache 2.0 license header. Should the license header be changed
for backport?

Stefan

Re: 1.6.8 Status

[Lieven Govaerts]

On Fri, Jan 8, 2010 at 4:16 PM, Hyrum K. Wright
 wrote:
> As a result of the various problems surrounding 1.6.7, we're pulling the 
> release, and will re-roll as 1.6.8.  The only blocker for rolling is the 
> r896522, r896547 which addresses a regression found in the 1.6.7 tarball (and 
> uncovered by the ruby bindings).  As soon as this fix is backported, I'll 
> roll 1.6.8.
>
> In the meantime, please revert the r896522, r896547 group, as well as any 
> other items which should be included in 1.6.8.

Did you mean s/revert/review/ ?

Lieven

Re: 1.6.8 Status

[Hyrum K. Wright]

On Jan 8, 2010, at 9:16 AM, Hyrum K. Wright wrote:

> As a result of the various problems surrounding 1.6.7, we're pulling the 
> release, and will re-roll as 1.6.8.  The only blocker for rolling is the 
> r896522, r896547 which addresses a regression found in the 1.6.7 tarball (and 
> uncovered by the ruby bindings).  As soon as this fix is backported, I'll 
> roll 1.6.8.
> 
> In the meantime, please revert the r896522, r896547 group, as well as any 
> other items which should be included in 1.6.8.

That should be *review the r896522, r896547 group*, not "revert".

> 
> Thanks,
> -Hyrum

1.6.8 Status

[Hyrum K. Wright]

As a result of the various problems surrounding 1.6.7, we're pulling the 
release, and will re-roll as 1.6.8.  The only blocker for rolling is the 
r896522, r896547 which addresses a regression found in the 1.6.7 tarball (and 
uncovered by the ruby bindings).  As soon as this fix is backported, I'll roll 
1.6.8.

In the meantime, please revert the r896522, r896547 group, as well as any other 
items which should be included in 1.6.8.

Thanks,
-Hyrum

Re: suspected bug report or feature request - tagging a sparse directory

[Johan Corveleyn]

On Fri, Jan 8, 2010 at 1:31 AM, Stas Cherkassky  wrote:
> Julian,
>
> I don't want to remove parts of the tree from the repository.
> What I want is, effectively, a way to independently mark separate
> parts of the tree with the same tag.
> (I tried to explain it in my example). I don't see how your method
> (using svn rm) does it.
>
> If a tag is a property of a file (like in CVS), it's natural operation :
> cvs tag -R dirA -t relX    # tags whatever files and versions I have in WC
> and then
> cvs tag -R dirB -t relX
> In the end I have both dirA and dirB tagged with same tag relX.
>
> If a tag is an object (like in Perforce), and it's property is a list
> of files/versions it applies to, it's also easily achievable in very
> similar manner - 2nd p4 tag call would just add more files to that
> property of the tag object.
>
> With SVN's implementation of tags (logical directory in repo), it
> would also be possible, had 'svn copy' behave like I suggested.
> IMHO, this way is more intuitive - that's what unix copy command would do.

You could also try to accomplish such a "sparse tag" by doing a pure
server-side copy, using multiple source targets (and with the
--parents option to automatically create the tag directory itself and
any other subdirs needed). Like:

% svn copy --parents $SVNROOT/myproj/dirA $SVNROOT/tags/rel_X/myproj
-m “tagging part A of myproj for the next integration”

Or if you want to tag only dirA, dirC and dirF, ignoring other dirXXX subdirs:

% svn copy --parents $SVNROOT/myproj/dirA $SVNROOT/myproj/dirC
$SVNROOT/myproj/dirF $SVNROOT/tags/rel_X/myproj -m “tagging part A, C
and F of myproj for the next integration”
(all the above on one line)

This makes use of the feature of svn copy that it can take multiple
source arguments:
usage: copy s...@rev]... DST

and the --parents option:
--parents: make intermediate directories


Ok, it might not be as convenient for you as creating the tag directly
out of your WC that you've already set up the correct way, but still
... it works.

HTH
Regards,
Johan

[PATCH] Augment the awful "200 OK" error message when can't connect to repository

[Julian Foad]

What happens if I accidentally specify a URL that's not a repository?
(Recent trunk build, Neon.)

> $ svn checkout https://svn.apache.org/repos/
> svn: OPTIONS of 'https://svn.apache.org/repos': 200 OK 
> (https://svn.apache.org)

This is a truly awful error message, appearing alone as it does. Google
reveals that many users have spent hours trying to track down the cause
of such errors. They appear in all repository operations, not just
checkout. For example,
 (during import;
unresolved) and

 (during checkout; SSH credentials not provided).


What do we need to do? Two things, I think:

  1. That low-level error report needs to be better. Any low-level
function that regards a "200 OK" response as an error must not just
create an error object saying "200 OK" alone but must wrap or replace
that with an error message that indicates what it was trying to do and
why an "OK" response is wrong.

  2. Each high level operation should aim to wrap any error from a
low-level function call with a higher-level explanation. For example,
"checkout" subcommand should wrap any error with "failed to check out
URL 'xxx'". It should not assume the low-level error provides enough
information. It should mention the high-level object (e.g. path or URL)
that failed so that the user can distinguish it within a batch of mostly
successful attempts.

The attached patch implements an instance of (2.) at the level of
connecting to a repository - svn_ra_open3(). It expands the above quoted
error to:

> $ svn checkout https://svn.apache.org/repos/
> svn: Unable to connect to a repository at URL 'https://svn.apache.org/repos'
> svn: OPTIONS of 'https://svn.apache.org/repos': 200 OK 
> (https://svn.apache.org)

The corresponding errors with svn: and file: URLs are then:

> $ svn checkout svn://localhost/repos
> svn: Unable to connect to a repository at URL 'svn://localhost/repos'
> svn: Can't connect to host 'localhost': Connection refused

> $ svn checkout file://localhost/repos
> svn: Unable to connect to a repository at URL 'file://localhost/repos'
> svn: Unable to open an ra_local session to URL
> svn: Unable to open repository 'file://localhost/repos'

There is now a little redundancy in the RA-local error. I think that is
acceptable and overall better than the previous situation.

It passes tests. I'll comit in a day or two if no objections.

- Julian

On failure to connect to the repository, give a consistent and readable
error message. This particularly helps in cases where the error message
from the specific RA layer is poor, such as RA-Neon's "200 OK" error message.

* subversion/libsvn_ra/ra_loader.c
  (svn_ra_open3): Wrap any error returned from the open_session() method.
--This line, and those below, will be ignored--

Index: subversion/libsvn_ra/ra_loader.c
===
--- subversion/libsvn_ra/ra_loader.c	(revision 897042)
+++ subversion/libsvn_ra/ra_loader.c	(working copy)
@@ -482,8 +482,10 @@ svn_error_t *svn_ra_open3(svn_ra_session
   session->pool = pool;
 
   /* Ask the library to open the session. */
-  SVN_ERR(vtable->open_session(session, repos_URL, callbacks, callback_baton,
-   config, pool));
+  SVN_ERR_W(vtable->open_session(session, repos_URL, callbacks, callback_baton,
+   config, pool),
+apr_psprintf(pool, "Unable to connect to a repository at URL '%s'",
+ repos_URL));
 
   /* Check the UUID. */
   if (uuid)