Stefan Sperling :
> Would reposurgeon in theory be able to use SVN dump files as a destination
> as well as a source?
I have considered this possibility. It would be difficult, and
it would expose me to support issues I don't think I want to deal with.
>Or perhaps the answer is to te
On Mon, Nov 19, 2012 at 2:47 PM, Julian Foad wrote:
> Johan Corveleyn wrote:
>
>> Daniel Shahaf wrote:
>>> Johan Corveleyn wrote:
I currently have a patch sitting here for adding
--diff-cmd to 'svnlook diff',
>>>
>>> I wonder what's the minimal change we could make to the cmdline
>>>
On Mon, Nov 19, 2012 at 9:04 PM, Paul Burba wrote:
> Recently Johan proposed supporting multiple targets for svnlook
> propget: http://svn.haxx.se/dev/archive-2012-11/0439.shtml
>
> One of the ideas that came of this was to make the output of 'svnlook
> (pl|pg)' mimic the output of 'svn (pl|pg)'.
On Mon, Nov 19, 2012 at 01:50:56PM -0500, C. Michael Pilato wrote:
> On 11/19/2012 01:45 PM, Eric S. Raymond wrote:
> > Some of you will recall that I did a lot of work early this year
> > on the dump stream documentation as part of an effort to enable
> > reposurgeon to read Subversion dump file
Recently Johan proposed supporting multiple targets for svnlook
propget: http://svn.haxx.se/dev/archive-2012-11/0439.shtml
One of the ideas that came of this was to make the output of 'svnlook
(pl|pg)' mimic the output of 'svn (pl|pg)'. This dovetails nicely
with my desire to add the ''show-inher
On 11/19/2012 01:45 PM, Eric S. Raymond wrote:
> Some of you will recall that I did a lot of work early this year
> on the dump stream documentation as part of an effort to enable
> reposurgeon to read Subversion dump files directly, translating
> Subversion histories into a DVCS-style commit DAG
Some of you will recall that I did a lot of work early this year
on the dump stream documentation as part of an effort to enable
reposurgeon to read Subversion dump files directly, translating
Subversion histories into a DVCS-style commit DAG that can then
be exported into git, hg, or bzr.
I am
On Mon, Nov 19, 2012 at 6:43 AM, Stefan Fuhrmann
wrote:
> A crashed writer process may leave a corrupt protorev and / or
> other incomplete files. There is no atomic incremental change
> here. The caller (client) using the crashed process is supposed
> to detect the crash and abandon the transacti
On 2012-11-19 16:20, Julian Foad wrote:
> let the *caller* check for duplicates.
I was, actually, also thinking about that at some point... I guess that's
the best call after all. I'll limit to propset/propedit and provide a
function to do the check.
/me still working on it
~Neels
signature.a
Julian Foad wrote on Mon, Nov 19, 2012 at 15:16:44 +:
> Stefan Fuhrmann wrote:
> > relatively rare and constructing an error object can be
> > expensive (NLS). svn_stringbuf_from_file2 is also a very
> > convenient function to use.
> I wonder if we could change our generic error handling scheme
A few questions about named_atomic.c:
Index: subversion/libsvn_subr/named_atomic.c
===
--- subversion/libsvn_subr/named_atomic.c (revision 1411269)
+++ subversion/libsvn_subr/named_atomic.c (working copy)
@@ -309,6 +309,7
On Mon, Nov 19, 2012 at 5:54 PM, Daniel Shahaf wrote:
> stef...@apache.org wrote on Mon, Nov 19, 2012 at 16:45:30 -:
> > @@ -74,7 +74,7 @@ Candidate changes:
> > Branch:
> > ^/subversion/branches/1.6.x-rep_write_cleanup
> > Votes:
> > - +1: breser, danielsh
> > + +1: bres
stef...@apache.org wrote on Mon, Nov 19, 2012 at 16:45:30 -:
> @@ -74,7 +74,7 @@ Candidate changes:
> Branch:
> ^/subversion/branches/1.6.x-rep_write_cleanup
> Votes:
> - +1: breser, danielsh
> + +1: breser, danielsh, stefan2
If you move this paragraph below the "Approved
On Mon, Nov 19, 2012 at 4:16 PM, Julian Foad wrote:
>
> Stefan Fuhrmann wrote:
>
> > Thanks for the review! The code should be multi-thread safe.
>
>
hm. That should read "should be multi-thread safe *now*".
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandis
Neels J Hofmeyr wrote:
> Thanks for your input, Markus!
>
> As so often with externals, things are more complex than one would think.
>
> - When an externals error occurs, the entire externals property remains
> unhandled. That needn't be so.
>
> - When an existing repos has duplicates, doing a
Neels J Hofmeyr writes:
> - To be able to issue a warning, the parsing function needs a new argument
> with a callback function (or something). Like this it can notify about more
> than one duplicate. It could still parse everything and return the parsed
> data, and externals updating could conti
On Mon, Nov 19, 2012 at 3:45 PM, Thomas Åkesson wrote:
> On 14 nov 2012, at 01:44, Daniel Shahaf wrote:
> > Philip Martin wrote on Tue, Nov 13, 2012 at 21:30:00 +:
> >> Perhaps we could start up a separate hook script process before
> >> allocating the large FSFS cache and then delegate the f
Stefan Fuhrmann wrote:
On Thu, Nov 15, 2012 at 6:16 PM, Julian Foad wrote:
>>stef...@apache.org wrote:
>>> URL: http://svn.apache.org/viewvc?rev=1397773&view=rev
>>> Log:
>>> Due to public request: apply rep-sharing to equal data reps within
>>> the same transaction.
>>>
>>> The idea is simple. W
On Mon, Nov 19, 2012 at 2:44 PM, Philip Martin
wrote:
> Philip Martin writes:
>
> > Stefan Fuhrmann writes:
> >
> >> On Mon, Nov 19, 2012 at 12:24 PM, Philip Martin
> >> wrote:
> >>
> >>> Stefan Fuhrmann writes:
> >>>
> >>> > As it turns out, your commit has only be the trigger but
> >>> > not
Thanks for your input, Markus!
As so often with externals, things are more complex than one would think.
- When an externals error occurs, the entire externals property remains
unhandled. That needn't be so.
- When an existing repos has duplicates, doing a simple update/checkout with
the new err
On 14 nov 2012, at 01:44, Daniel Shahaf wrote:
> Philip Martin wrote on Tue, Nov 13, 2012 at 21:30:00 +:
>> Perhaps we could start up a separate hook script process before
>> allocating the large FSFS cache and then delegate the fork/exec to that
>> smaller process?
>
> If so, let's have that
On Thu, Nov 15, 2012 at 6:16 PM, Julian Foad wrote:
> Hi Stefan. Some review questions and comments...
>
> stef...@apache.org wrote:
> > URL: http://svn.apache.org/viewvc?rev=1397773&view=rev
> > Log:
> > Due to public request: apply rep-sharing to equal data reps within
> > the same transaction.
C. Michael Pilato wrote:
>> User julianfoad changed the following:
>>
>> What |Old value |New value
>> ===
>> Target milestone|--- |unscheduled
>>
>> --- Additional comments f
On 11/19/2012 09:13 AM, Daniel Shahaf wrote:
> Another thing we could do is warn when unrecognised options are found in
> the config file (~/.subversion/*) or in the --config-option command-line
> option.
>
> This would be an independent improvement, i.e., it neither blocks nor
> is blocked by the
Julian Foad wrote on Mon, Nov 19, 2012 at 14:08:34 +:
> C. Michael Pilato wrote:
>
> > On 11/18/2012 10:56 PM, Daniel Shahaf wrote:
> >> Julian Foad wrote on Mon, Nov 19, 2012 at 02:50:46 +:
> >>> Thoughts, objections?
> >>
> >> Another related trap is setting a revprop as a nodeprop,
On 11/19/2012 09:12 AM, julianf...@tigris.org wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4261
>
>
>
> User julianfoad changed the following:
>
> What|Old value |New value
>
C. Michael Pilato wrote:
> On 11/18/2012 10:56 PM, Daniel Shahaf wrote:
>> Julian Foad wrote on Mon, Nov 19, 2012 at 02:50:46 +:
>>> Thoughts, objections?
>>
>> Another related trap is setting a revprop as a nodeprop, or vice-versa:
>> svn commit --with-revprop=svn:eol-style=native -m
Johan Corveleyn wrote:
> Daniel Shahaf wrote:
>> Johan Corveleyn wrote:
>>> I currently have a patch sitting here for adding
>>> --diff-cmd to 'svnlook diff',
>>
>> I wonder what's the minimal change we could make to the cmdline
>> client such that it can operate on transactions (and thus vo
Philip Martin writes:
> Stefan Fuhrmann writes:
>
>> On Mon, Nov 19, 2012 at 12:24 PM, Philip Martin
>> wrote:
>>
>>> Stefan Fuhrmann writes:
>>>
>>> > As it turns out, your commit has only be the trigger but
>>> > not the root cause.
>>> >
>>> > serf_trunk/allocator.c, serf_bucket_allocator_cr
On 11/18/2012 10:56 PM, Daniel Shahaf wrote:
> Julian Foad wrote on Mon, Nov 19, 2012 at 02:50:46 +:
>> Thoughts, objections?
>>
>
> Another related trap is setting a revprop as a nodeprop, or vice-versa:
> svn commit --with-revprop=svn:eol-style=native -mm foo.c
> svn propset svn:log
Stefan Fuhrmann writes:
> On Mon, Nov 19, 2012 at 12:24 PM, Philip Martin
> wrote:
>
>> Stefan Fuhrmann writes:
>>
>> > As it turns out, your commit has only be the trigger but
>> > not the root cause.
>> >
>> > serf_trunk/allocator.c, serf_bucket_allocator_create(), line 147:
>> >
>> > /* #
On Mon, Nov 19, 2012 at 11:38 AM, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Mon, Nov 19, 2012 at 09:43:30 +0100:
>> (on a related note, I currently have a patch sitting here for adding
>> --diff-cmd to 'svnlook diff', but those changes are local to the
>
> I wonder what's the minimal change
On Mon, Nov 19, 2012 at 12:24 PM, Philip Martin
wrote:
> Stefan Fuhrmann writes:
>
> > As it turns out, your commit has only be the trigger but
> > not the root cause.
> >
> > serf_trunk/allocator.c, serf_bucket_allocator_create(), line 147:
> >
> > /* ### this implies buckets cannot cross a
Stefan Fuhrmann writes:
> As it turns out, your commit has only be the trigger but
> not the root cause.
>
> serf_trunk/allocator.c, serf_bucket_allocator_create(), line 147:
>
> /* ### this implies buckets cannot cross a fork/exec. desirable?
> *
> * ### hmm. it probably also means
Johan Corveleyn wrote on Mon, Nov 19, 2012 at 09:43:30 +0100:
> (on a related note, I currently have a patch sitting here for adding
> --diff-cmd to 'svnlook diff', but those changes are local to the
I wonder what's the minimal change we could make to the cmdline client
such that it can operate on
35 matches
Mail list logo
