Re: RFC: Our own Wiki at the ASF

Julian Foad wrote on Fri, Sep 30, 2011 at 13:02:24 +0100: > Daniel Shahaf wrote: > > Given that you just published a Google doc in another thread, +1 to > > having a wiki :-) > > That's exactly what prompted me to request one at this time. > > If no objections by say the end of today, would you b

Re: [Ticket #78] Apache Subversion 1.7.0-rc4 Released

They are subscribed to announce@a.o. I'll handle it ACT-Support Department wrote on Fri, Sep 30, 2011 at 15:21:33 -0300: > This is a notification from the Help Desk. > > > > > On Sep 30, 2011 @ 03:14 pm, hwri...@apache.org wrote: > I'm happy to announce the release of Apache Subversion 1.7.0-

Re: svn merge operation extremely slow

On Fri, Sep 30, 2011 at 3:29 PM, Kyle Leber wrote: > I've encountered what I think is a problem with subversion, but I'm not > completely sure (and according to the online instructions I should bring it > up here prior to filing a bug). Actually, the instructions on http://subversion.apache.org/i

[Ticket #78] Apache Subversion 1.7.0-rc4 Released

This is a notification from the Help Desk. On Sep 30, 2011 @ 03:14 pm, hwri...@apache.org wrote: I'm happy to announce the release of Apache Subversion 1.7.0-rc4. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#pre-releases The SHA1 checksums ar

[Ticket #8] Apache Subversion 1.7.0-rc4 Released

This is a notification from the Help Desk. On Sep 30, 2011 @ 03:04 pm, hwri...@apache.org wrote: I'm happy to announce the release of Apache Subversion 1.7.0-rc4. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#pre-releases The SHA1 checksums ar

Re: RFC: Our own Wiki at the ASF

On Sep 29, 7:50 pm, Julian Foad wrote: > I'd like us to have a Wiki. I understand we can have one on the ASF just > by asking.  My use for it would be to host developer-to-developer > information about designs in progress.  Shall I just go ahead and ask > the ASF (via danielsh) so set it up? > > H

Re: Fwd: [Daniel Shahaf: Long-standing corruption on svn.apache.org]

Daniel Shahaf writes: >> Here is a node-revision on eris: > [eris == svn.us.apache.org] >> >> [[[ >> id: 0-836401.0.r891679/11455 >> type: dir >> pred: 0-836401.0.r891672/13070 >> count: 43983 >> text: 891679 11072 370 370 b03cc8a5e429084dd4fdf39d6fe46b07 >> props: 866503 8246 73 0 d34667037ecfd

Fwd: [Daniel Shahaf: Long-standing corruption on svn.apache.org]

tldr: a node-rev on svn.us differs in two ways from the same noderev on svn.eu, with at least one of the differences causing user-visible wrong answers to history queries. Any information towards getting to the bottom of this would be appreciated. In particular, if any of those of you with local

Re: Merge info display

On Fri, Sep 30, 2011 at 7:24 AM, Julian Foad wrote: > I've been thinking about a bunch of issues related to merging and how to > help users to avoid some of the common pitfalls.  One subset of my > thoughts is on how we can present information about merges in a more > user-friendly high-level way

Re: server-side log cache

On Thu, Sep 22, 2011 at 08:43:14PM +0200, Stefan Fuhrmann wrote: > >>>This looks very interesting. > >>> > >>>What about FSFS-specific requirements? > >>See assumptions above, this may require a different > >>data structure. But I think that noderev dependencies > >>will turn out to be redundant if

Re: Incomplete working nodes

Philip Martin writes: > Another solution would be to have svn_wc__db_read_info return > status=added for incomplete working nodes so they would be treated as > added automatically. We would need to have svn_wc__db_scan_addition > return status=incomplete so that the incomplete status is still >

Re: Merge info display

On Fri, 2011-09-30 at 14:42 +0200, Stefan Sperling wrote: > On Fri, Sep 30, 2011 at 12:24:04PM +0100, Julian Foad wrote: > > I've been thinking about a bunch of issues related to merging and how to > > help users to avoid some of the common pitfalls. One subset of my > > thoughts is on how we can

Re: Merge info display

I (Julian Foad) wrote: > I'm writing down my thoughts in this public document > ; > see especially under the "Reporting ..." section headings. Apparently that wasn't publicly visible. So

Re: Merge info display

On Fri, 2011-09-30 at 17:27 +0400, Ivan Zhakov wrote: > On Fri, Sep 30, 2011 at 17:20, Johan Corveleyn wrote: > > On Fri, Sep 30, 2011 at 2:42 PM, Stefan Sperling wrote: > >> In principle, we should keep the current output by default (for backwards > >> compat), and add a new switch that enables

svn merge operation extremely slow

I've encountered what I think is a problem with subversion, but I'm not completely sure (and according to the online instructions I should bring it up here prior to filing a bug). Basically, we're trying to merge a rather large collection of fixes back in our trunk. I check out a fresh copy of th

Incomplete working nodes

A couple of recent issues have revealed that we don't handle incomplete working nodes properly: http://subversion.tigris.org/issues/show_bug.cgi?id=4025 http://subversion.tigris.org/issues/show_bug.cgi?id=4026 These nodes happen when a wc-to-wc copy is interrupted, and possibly when an incomplete

Re: Merge info display

On Fri, Sep 30, 2011 at 17:20, Johan Corveleyn wrote: > On Fri, Sep 30, 2011 at 2:42 PM, Stefan Sperling wrote: >> On Fri, Sep 30, 2011 at 12:24:04PM +0100, Julian Foad wrote: >>> I've been thinking about a bunch of issues related to merging and how to >>> help users to avoid some of the common p

Re: Merge info display

On Fri, Sep 30, 2011 at 2:42 PM, Stefan Sperling wrote: > On Fri, Sep 30, 2011 at 12:24:04PM +0100, Julian Foad wrote: >> I've been thinking about a bunch of issues related to merging and how to >> help users to avoid some of the common pitfalls.  One subset of my >> thoughts is on how we can pres

Re: Merge info display

On Fri, Sep 30, 2011 at 12:24:04PM +0100, Julian Foad wrote: > I've been thinking about a bunch of issues related to merging and how to > help users to avoid some of the common pitfalls. One subset of my > thoughts is on how we can present information about merges in a more > user-friendly high-le

Re: RFC: Our own Wiki at the ASF

Given that you just published a Google doc in another thread, +1 to having a wiki :-) Julian Foad wrote on Thu, Sep 29, 2011 at 18:50:48 +0100: > I'd like us to have a Wiki. I understand we can have one on the ASF just > by asking. My use for it would be to host developer-to-developer > informati

Re: Thought experiment - follow logs back before r1 into previous repository

Julian Foad wrote on Fri, Sep 30, 2011 at 12:17:09 +0100: > To record my own opinion: I think it's a fine idea that users in that > situation should be able to do that sort of thing but I don't think that > functionality belongs in "svn" as I think it's an uncommon use case and > can't be cleanly a

Re: Thought experiment - follow logs back before r1 into previous repository

Julian Foad wrote on Fri, Sep 30, 2011 at 10:40:31 +0100: > I think teaching "svn blame" to view the old repo would be harder: > it would require more intrusive code changes in svn_client_blame(). > It's not theoretically difficult to do, of course, but perhaps the > code-to-value ratio would n

Merge info display

I've been thinking about a bunch of issues related to merging and how to help users to avoid some of the common pitfalls. One subset of my thoughts is on how we can present information about merges in a more user-friendly high-level way so that each time a user runs "svn merge" or "svn mergeinfo"

Re: Thought experiment - follow logs back before r1 into previous repository

To record my own opinion: I think it's a fine idea that users in that situation should be able to do that sort of thing but I don't think that functionality belongs in "svn" as I think it's an uncommon use case and can't be cleanly and generally supported -- it's rather a hack. If we supported thi

Re: Thought experiment - follow logs back before r1 into previous repository

Konstantin Kolinko wrote on Fri, Sep 30, 2011 at 14:15:48 +0400: > 2011/9/30 Julian Foad : > > Perhaps we'd set > > a revprop on (new) r0 or r1 pointing to the old repo URL so that this > > info is configured in a single place.  The two sets of revision numbers > > in the output would be confusing

Re: Thought experiment - follow logs back before r1 into previous repository

2011/9/30 Julian Foad : > Perhaps we'd set > a revprop on (new) r0 or r1 pointing to the old repo URL so that this > info is configured in a single place.  The two sets of revision numbers > in the output would be confusing so we may want to consider tagging the > old and/or the new revnums with so

Thought experiment - follow logs back before r1 into previous repository

I want to share with you an idea that came to me from a customer. I'm not at all proposing that anybody should do this, I'm just curious what you think. Imagine, if you will, that we are coders working in a Subversion repository that has grown very large and that for IT reasons a decision has bee