Hi,
Receiving this when building 1.7.2. I think I have all dependencies
satisfied except BerkelyDB, which I couldn't find in Ubuntu's 11.10
repositories.
/bin/bash /home/gbell/src/subversion/libtool --tag=CC --silent
--mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
-D_LARGEFILE64_SO
On Thu, Dec 15, 2011 at 04:04:13PM -0600, Peter Samuelson wrote:
>
> [Philip Martin]
> > If we had such a flag in fsfs.conf (Stefan suggests
> > "eat-my-data=yes") the code could write all the same data in the same
> > order but avoid making any flush calls thus allowing the OS to order
> > physic
[Philip Martin]
> If we had such a flag in fsfs.conf (Stefan suggests
> "eat-my-data=yes") the code could write all the same data in the same
> order but avoid making any flush calls thus allowing the OS to order
> physical writes for optimum speed.
Given the main use case is a distinct svnadmin
> Peter Samuelson wrote on Wed, Dec 14, 2011 at 18:16:27 -0600:
> > What you want is to pipe these emails into 'wdiff -ct | less -r'. With
[Daniel Shahaf]
> Thanks for the tip!
>
> What version of wdiff do you have? On my system I have 0.6.3-1, which
> seems to be the latest, but doesn't have
On Dec 15, 2011 1:26 PM, "Stefan Sperling" wrote:
>
> On Thu, Dec 15, 2011 at 01:04:04PM -0500, Greg Stein wrote:
> > Couldn't we just make that an option for loading, but not provide such a
> > feature for normal operation? That seems safer to me, and solves the
actual
> > use case.
>
> That woul
Hello.
I have some reports of the svnserve daemon dying under vanilla fedora 15.
My story is simple...
I was need svn repository for my students on the course C/C++
programming, like each semester.
So, I installed vanilla Fedora 15, configure and start vanilla svn
1.6.17 with svn:// (svnserve)
Daniel Shahaf wrote on Thu, Dec 15, 2011 at 20:27:22 +0200:
> C. Michael Pilato wrote on Thu, Dec 15, 2011 at 11:08:25 -0500:
> > On 12/15/2011 10:24 AM, Daniel Shahaf wrote:
> > > That's an interesting approach. But can we do without the log files?
> > > Is there an easy way to, given N, capture
On Thu, Dec 15, 2011 at 08:27:22PM +0200, Daniel Shahaf wrote:
> Stefan says the new hotcopy --incremental code recopies all historical
> revprop files.
If they have changed, yes.
C. Michael Pilato wrote on Thu, Dec 15, 2011 at 11:08:25 -0500:
> On 12/15/2011 10:24 AM, Daniel Shahaf wrote:
> > That's an interesting approach. But can we do without the log files?
> > Is there an easy way to, given N, capture all the table rows that belong
> > to revisions youngest than rN?
>
On Thu, Dec 15, 2011 at 01:04:04PM -0500, Greg Stein wrote:
> Couldn't we just make that an option for loading, but not provide such a
> feature for normal operation? That seems safer to me, and solves the actual
> use case.
That would require revving the repos and fs APIs.
Hence the idea of putti
Couldn't we just make that an option for loading, but not provide such a
feature for normal operation? That seems safer to me, and solves the actual
use case.
+1 on the flag name :-)
Cheers,
-g
On Dec 15, 2011 10:59 AM, "Philip Martin"
wrote:
> From a discussion on IRC:
>
> A BDB repository all
C. Michael Pilato wrote on Thu, Dec 15, 2011 at 11:08:25 -0500:
> On 12/15/2011 10:24 AM, Daniel Shahaf wrote:
> > That's an interesting approach. But can we do without the log files?
> > Is there an easy way to, given N, capture all the table rows that belong
> > to revisions youngest than rN?
>
On 12/15/2011 10:24 AM, Daniel Shahaf wrote:
> That's an interesting approach. But can we do without the log files?
> Is there an easy way to, given N, capture all the table rows that belong
> to revisions youngest than rN?
I suppose that depends on what you mean by "easy". We'd need a whole bun
>From a discussion on IRC:
A BDB repository allows the admin to set DB_TXN_NOSYNC in the DBD
configuration file, this allows the admin to trade performance for
robustness. We could do something similar in FSFS. When loading a
dumpfile into a FSFS repository I see 13 calls to fsync per revision o
On Thu, Dec 15, 2011 at 10:15 AM, Paul Burba wrote:
> On Thu, Dec 15, 2011 at 7:53 AM, Julian Foad
> wrote:
>> Thanks Paul.
>>
>> Paul Burba wrote:
>>
>>> Julian Foad wrote:
Here's a patch to reject silly merge attempts, which up to now give
silly results.
This does not app
cmpil...@tigris.org wrote on Thu, Dec 15, 2011 at 07:04:44 -0800:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4081
>
>
>
> User cmpilato changed the following:
>
> What|Old value |New value
> =
On Thu, Dec 15, 2011 at 7:53 AM, Julian Foad wrote:
> Thanks Paul.
>
> Paul Burba wrote:
>
>> Julian Foad wrote:
>>> Here's a patch to reject silly merge attempts, which up to now give
>>> silly results.
>>>
>>> This does not apply to all merges (general 2-URL and cherry-pick
>>> merges), but th
On 12/15/2011 07:53 AM, Julian Foad wrote:
> This "sync merge from my own history" operation seems bogus. I notice
> that (without my patch) it merges changes from the future *and* records
> mergeinfo
> for them. Surely we didn't ever intend that?
Subversion has supported "sync merge from my own
On 12/15/2011 04:53 AM, julianf...@apache.org wrote:
> Author: julianfoad
> Date: Thu Dec 15 09:53:59 2011
> New Revision: 1214677
>
> URL: http://svn.apache.org/viewvc?rev=1214677&view=rev
> Log:
> Teach svn_client__get_youngest_common_ancestor() to output the ancestor as a
> URL as well as a rel
Thanks Paul.
Paul Burba wrote:
> Julian Foad wrote:
>> Here's a patch to reject silly merge attempts, which up to now give
>> silly results.
>>
>> This does not apply to all merges (general 2-URL and cherry-pick
>> merges), but the commonly used 'sync' and 'reintegrate' forms of
>> merge on
s...@apache.org wrote on Thu, Dec 15, 2011 at 11:03:08 -:
> Author: stsp
> Date: Thu Dec 15 11:03:08 2011
> New Revision: 1214697
>
> URL: http://svn.apache.org/viewvc?rev=1214697&view=rev
> Log:
> New and improved implementation of 'hotcopy' for FSFS.
...
> Modified: subversion/trunk/subversi
On Thu, Dec 15, 2011 at 11:44 AM, Daniel Shahaf wrote:
> Roderich Schupp wrote on Thu, Dec 15, 2011 at 11:32:40 +0100:
>> I think the latter. The code is in subversion/libsvn_repos/dump.c starting
>> around line 318. Some people might call that an ugly hack :)
>
> Yeah. I wonder why that code doe
Roderich Schupp wrote on Thu, Dec 15, 2011 at 11:32:40 +0100:
> On Thu, Dec 15, 2011 at 11:14 AM, Daniel Shahaf
> wrote:
> > Is this by design or by accident of implementation?
>
> I think the latter. The code is in subversion/libsvn_repos/dump.c starting
> around line 318. Some people might cal
On Thu, Dec 15, 2011 at 11:14 AM, Daniel Shahaf wrote:
> Is this by design or by accident of implementation?
I think the latter. The code is in subversion/libsvn_repos/dump.c starting
around line 318. Some people might call that an ugly hack :)
> svn_delta_editor_t has no concept of 'replace' an
roderich.sch...@googlemail.com wrote on Thu, Dec 15, 2011 at 01:33:22 -0800:
> Thus a dump consumer can simply store the node records (in one
> revision) as a hash (associative array) with Node-path as the key. The
> only excption is that it must be prepared to "upgrade" a "delete" to
> a "replace"
On Dec 15, 10:33 am, "roderich.sch...@googlemail.com"
wrote:
>> 4. What are the detailed semantics of "change" with copyfrom? I
> It's an "add-with-history" immediately followed by a modification (of
> contents and/or properties) of the added path.
Sorry, I was wrong. "change" with copyfrom is
On Dec 14, 1:37 pm, "Eric S. Raymond" wrote:
> 1. Is delete on a directory with children expected to succeed or fail?
Succeed. A delete on a directory actually deletes the whole subtree
below it.
> 3. Is add on an existing path expected to fail?
Yes.
> 4. What are the detailed semantics of "c
Peter Samuelson wrote on Wed, Dec 14, 2011 at 18:16:27 -0600:
>
> [Daniel Shahaf]
> > > Is there any way to get line-based (rather than paragraph-based) diffs
> > > from the wiki? That would enable reviewing them.
>
> [C. Michael Pilato]
> > You are seeing line-based diffs. It's just that tha
28 matches
Mail list logo
