No worries! Figured you were already away for the night, too.
Or we can say you owe me a quick fix next time I bunk up the build ;-)
Cheers,
-g
On Wed, Jul 20, 2011 at 22:55, Paul Burba wrote:
> Sorry about that. r1149001 was part of a larger patch I'm working on, but
> obviously it didn't sta
Sorry about that. r1149001 was part of a larger patch I'm working on, but
obviously it didn't stand on it's own. Thanks for fixing.
Paul
On Jul 20, 2011 10:28 PM, "Greg Stein" wrote:
> Fixed in r1149010.
>
> On Wed, Jul 20, 2011 at 22:20, Greg Stein wrote:
>> On Wed, Jul 20, 2011 at 21:11, w
Fixed in r1149010.
On Wed, Jul 20, 2011 at 22:20, Greg Stein wrote:
> On Wed, Jul 20, 2011 at 21:11, wrote:
>>...
>> +++ subversion/trunk/subversion/libsvn_client/merge.c Thu Jul 21 01:11:27
>> 2011
>>...
>> @@ -8146,10 +8146,10 @@ remove_noop_subtree_ranges(const char *u
>>
On Wed, Jul 20, 2011 at 21:11, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_client/merge.c Thu Jul 21 01:11:27 2011
>...
> @@ -8146,10 +8146,10 @@ remove_noop_subtree_ranges(const char *u
> youngest_gap_rev->end,
>
Looks like this busted the buildbots.
On Wed, Jul 20, 2011 at 21:11, wrote:
> Author: pburba
> Date: Thu Jul 21 01:11:27 2011
> New Revision: 1149001
>
> URL: http://svn.apache.org/viewvc?rev=1149001&view=rev
> Log:
> * subversion/libsvn_client/merge.c
> (remove_noop_subtree_ranges): Use local
On Tue, Jul 19, 2011 at 19:53, Greg Stein wrote:
> On Tue, Jul 19, 2011 at 10:41, C. Michael Pilato wrote:
>>...
>> release-readiness? What about ra_serf's "default-ness" -- is it in the
>> appropriate state based on that library's readiness at this moment?
>
> The only pending serf issue is my
> On Wed, 20 Jul 2011 16:06 -0400, "C. Michael Pilato"
> wrote:
> > This is all I saw. Saw no CIA notification in #svn-dev. Saw no commit mail
> > come through. When I updated my working copy, I got my own changes back
I generated a commit mail manually.
Blair's "post-commit FS processing" work (aka: svn_fs_commit_txn() returns an
error but also returns a non-SVN_INVALID_REVNUM revision number) was backported
to 1.6.17, but is not in 1.6.16 which svn.a.o runs?
grep -2w svn_fs_commit_txn
https://svn.apache.org/repos/asf/subversion/tags/1.6.16/su
I committed r1148918 a few minutes ago, and when I did, I saw this:
$ svn ci subversion/ -F ~/log_message.txt
Sendingsubversion/libsvn_ra_local/ra_plugin.c
Transmitting file data .
subversion/svn/commit-cmd.c:181: (apr_err=200030)
subversion/libsvn_client/commit.c:852: (apr_err=200030)
sub
[Julian Foad]
> In fact, this must imply that you *can* get conflicts if any of the
> changes on trunk after rX conflicts with the "feature". But the
> recommended work flow would be to do the last "catch-up" (which
> defines X) just before the re-integrate, so the opportunity for such
> conflict
Greg Stein wrote on 07/20/2011 12:32:42 PM:
> > Somewhat off-topic, but there was also previous concern that
> > the multiple connections that serf uses might overly stress some
> > larger servers. Do we have any idea how many additional connections
> > a typical server would see? For example, i
On Wed, Jul 20, 2011 at 19:51, C. Michael Pilato wrote:
> It seems to me that the fixes Johan made for case-only renames (obviously
> empowered by WC-NG) could be the sort of high-profile bugfix that merit a
> mention in the release notes.
+1, this is really important fix for Windows users.
--
[straying from original topic; changed subject]
On Wed, Jul 20, 2011 at 13:02, wrote:
>...
>> Not saying it shouldn't be fixed... just saying that I'm unsure that
>> it is a *release-blocker*. Or more precisely, that it is an issue that
>> would cause serf to no longer be the default.
>
> I gues
> From: Greg Stein
> On Wed, Jul 20, 2011 at 09:23, wrote:
> > Greg Stein wrote on 07/19/2011 06:53:12 PM:
> >> On Tue, Jul 19, 2011 at 10:41, C. Michael Pilato
> >> wrote:
> >> >...
> >> > release-readiness? What about ra_serf's "default-ness" -- is it
in the
> >> > appropriate state base
On Wed, 2011-07-20 at 11:51 -0400, C. Michael Pilato wrote:
> It seems to me that the fixes Johan made for case-only renames (obviously
> empowered by WC-NG) could be the sort of high-profile bugfix that merit a
> mention in the release notes. I certainly don't want to start a torrent of
> discuss
Philip Martin wrote on Wed, Jul 20, 2011 at 15:12:51 +0100:
> Daniel Shahaf writes:
>
> > Mathias Weinert wrote on Wed, Jul 20, 2011 at 14:59:23 +0200:
> >>
> >> each time when I am loading a certain dump file on Windows which
> >> contains one revision with over 100K changed paths I get the err
On Wed, Jul 20, 2011 at 09:23, wrote:
> Greg Stein wrote on 07/19/2011 06:53:12 PM:
>> On Tue, Jul 19, 2011 at 10:41, C. Michael Pilato
>> wrote:
>> >...
>> > release-readiness? What about ra_serf's "default-ness" -- is it in the
>> > appropriate state based on that library's readiness at thi
It seems to me that the fixes Johan made for case-only renames (obviously
empowered by WC-NG) could be the sort of high-profile bugfix that merit a
mention in the release notes. I certainly don't want to start a torrent of
discussion about which bugfixes "make the cut" -- but maybe there are a
han
Hyrum K Wright wrote:
> On Wed, Jul 20, 2011 at 7:14 AM, Gavin "Beau" Baumanis
> wrote:
> > When you create a repository, (with 1.6.16) - in the root directory
> is a README.TXT that contains the following text;
> >
> > Visit http://subversion.tigris.org/ for more information.
>
> 1.7.x gives the
On Wed, Jul 20, 2011 at 7:14 AM, Gavin "Beau" Baumanis
wrote:
> Hi There,
>
> As non developer, I am not sure where it lives in the source code to check
> for myself,
> I did : find . |grep README.TXT - but turned up what all looked like
> Developer / Packager notes.
>
> None the less, I just sa
Daniel Shahaf wrote:
> One alternative solution is having svn_fs_fs__verify() stat() the DB
> file for existence before attempting to operate on it.
>
> I don't think it's the most elegant thing in the world, but it avoids
> spuriously creating the DB file without complicating the common case
> lo
On Wed, Jul 20, 2011 at 03:27:02PM +0100, Julian Foad wrote:
> Stefan Sperling wrote:
> > It does not generate conflicts because of the way REV1 is chosen,
> > and because of the way PATH1 and PATH2 are chosen.
>
> In fact, this must imply that you *can* get conflicts if any of the
> changes on tr
Stefan Sperling wrote:
> On Wed, Jul 20, 2011 at 01:13:09PM +0100, Julian Foad wrote:
> > There are (broadly speaking) two ways we could perform a "re-integrate"
> > merge. The "general" way is to do it by using a sufficiently clever
> > general-purpose merge algorithm to merge all the changes tha
On Wed, Jul 20, 2011 at 09:41:48AM -0400, Andy Singleton wrote:
> The non-special merge case is also common even in projects that use
> Subversion. For example, consider the case where we have a release
> branch and a development trunk. I see this in almost every serious
> subversion project. We
Hi Daniel,
Thanks for looking into this issue. See my comments below.
>> >> FWIW, I think UTF-8 is a fine choice, especially if we've been internally
>> >> handling this string as UTF-8 already. But let's document the fact
>> >> somewhere, please (preferably in the pre-lock-hook template comment
Daniel Shahaf writes:
> Mathias Weinert wrote on Wed, Jul 20, 2011 at 14:59:23 +0200:
>>
>> each time when I am loading a certain dump file on Windows which
>> contains one revision with over 100K changed paths I get the error
>> "Can't open file
>> 'c:\Repositories\test\db\transactions\5445-479
I do not think that the reverse merge strategy is the same as doing
multiple forward merges, and I do not think it covers enough cases. For
example, In your original example, you proposed merging in to branch
Feature, where
Feature = F+(R+S+RSFix)
You proposed "unmerging" (or even reverting)
Mathias Weinert wrote on Wed, Jul 20, 2011 at 14:59:23 +0200:
> Hi,
>
> each time when I am loading a certain dump file on Windows which
> contains one revision with over 100K changed paths I get the error
> "Can't open file
> 'c:\Repositories\test\db\transactions\5445-479.txn\next-ids': The
> req
Julian and Stefan, thank you for this distinction between the
"special" merge case, where we can grab all of the changes between two
revisions, and the "general" merge case. That really clarifies the
discussion.
The point I am making is that Subversion needs to support more of the
"general"
Greg Stein wrote on 07/19/2011 06:53:12 PM:
> On Tue, Jul 19, 2011 at 10:41, C. Michael Pilato
wrote:
> >...
> > release-readiness? What about ra_serf's "default-ness" -- is it in
the
> > appropriate state based on that library's readiness at this moment?
>
> The only pending serf issue is m
Hi,
each time when I am loading a certain dump file on Windows which
contains one revision with over 100K changed paths I get the error
"Can't open file
'c:\Repositories\test\db\transactions\5445-479.txn\next-ids': The
requested operation cannot be performed on a file with a user-mapped
Sorry Noorul, but -1 on adding more UI complexity without better
justification.
- Julian
On Wed, 2011-07-20 at 16:47 +0530, Noorul Islam K M wrote:
> Julian Foad writes:
>
> > Noorul Islam K M wrote:
> >
> >> From issue tracker:
> >>
On Wed, Jul 20, 2011 at 01:13:09PM +0100, Julian Foad wrote:
> There are (broadly speaking) two ways we could perform a "re-integrate"
> merge. The "general" way is to do it by using a sufficiently clever
> general-purpose merge algorithm to merge all the changes that are unique
> to the branch, o
Philip Martin writes:
> Noorul Islam K M writes:
>
>> Philip Martin writes:
>>
>>> Noorul Islam K M writes:
>>>
+static svn_error_t *
+props_only_receiver(void *baton, svn_log_entry_t *log_entry, apr_pool_t
*pool)
+{
+ props_only_receiver_baton_t *rb = baton;
+
Hi There,
As non developer, I am not sure where it lives in the source code to check for
myself,
I did : find . |grep README.TXT - but turned up what all looked like Developer
/ Packager notes.
None the less, I just saw something that I thought should raise in case it had
been overlooked.
Whe
Hi Andy.
Let me talk a bit about 're-integrate' merges, which are a special case
of 'cyclic' merges.
Stepping back, just to make sure we all understand the concept and use
the same terminlogy, we can define the high-level concept of a
"re-integrate" merge in terms of the work flow of a "feature b
Noorul Islam K M writes:
> Philip Martin writes:
>
>> Noorul Islam K M writes:
>>
>>> +static svn_error_t *
>>> +props_only_receiver(void *baton, svn_log_entry_t *log_entry, apr_pool_t
>>> *pool)
>>> +{
>>> + props_only_receiver_baton_t *rb = baton;
>>> +
>>> + if (log_entry->changed_paths2)
Philip Martin writes:
> Noorul Islam K M writes:
>
>> +static svn_error_t *
>> +props_only_receiver(void *baton, svn_log_entry_t *log_entry, apr_pool_t
>> *pool)
>> +{
>> + props_only_receiver_baton_t *rb = baton;
>> +
>> + if (log_entry->changed_paths2)
>> +{
>> + apr_array_header_t
Noorul Islam K M writes:
> +static svn_error_t *
> +props_only_receiver(void *baton, svn_log_entry_t *log_entry, apr_pool_t
> *pool)
> +{
> + props_only_receiver_baton_t *rb = baton;
> +
> + if (log_entry->changed_paths2)
> +{
> + apr_array_header_t *sorted_paths;
> + int i;
> +
Julian Foad writes:
> Noorul Islam K M wrote:
>
>> From issue tracker:
>> ==
>> Add an option to ignore files with only property changes and no content
>> changes.
>> e.g. svn log --ignore-properties
>>
>> Motivatio
On Wed, Jul 20, 2011 at 10:49:03AM -, rhuij...@apache.org wrote:
> + * r1148566
> + Fix a memory leak in svn merge.
> + Justification:
> + Memory leaks are bad.
> + Votes:
> + +1: stsp
> + -0: rhuijben (r1148588 fixes the immediate problems and this code can
> use
> +
On Wed, Jul 20, 2011 at 12:40:06PM +0200, Bert Huijben wrote:
> It might be useful to use editor v2 for sending over file moves, but this is
> not a requirement for handling file moves.
>
> We overloaded the entry props feature a few times before and there is no
> reason why we can't get file move
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: woensdag 20 juli 2011 11:55
> To: Greg Stein
> Cc: Hyrum K Wright; Subversion Development
> Subject: Re: Editor v2: What's The Plan?
>
> On Tue, Jul 19, 2011 at 11:43:06PM -0400, Greg Stein wrote:
> > On Tue, Jul
Noorul Islam K M wrote:
> From issue tracker:
> ==
> Add an option to ignore files with only property changes and no content
> changes.
> e.g. svn log --ignore-properties
>
> Motivation: many users are not interested
On Tue, Jul 19, 2011 at 11:43:06PM -0400, Greg Stein wrote:
> On Tue, Jul 19, 2011 at 21:27, Hyrum K Wright wrote:
> > And for the record, what are the benefits expected from all this work?
>
> Atomicity, cleaner memory/pool handling, better debug support, much
> more understandable, more clear a
I thought of replying to the following thread, but unfortunately I lost
all my mails. So I am quoting the link.
http://svn.haxx.se/dev/archive-2011-07/0005.shtml
>From issue tracker:
==
Add an option to ignore files
On Tue, Jul 19, 2011 at 08:48:02PM -0400, Greg Stein wrote:
> On Tue, Jul 19, 2011 at 20:29, Greg Stein wrote:
> > On Tue, Jul 19, 2011 at 20:10, Greg Stein wrote:
> >> On Tue, Jul 19, 2011 at 17:51, wrote:
> >>>...
> >>> * subversion/libsvn_client/merge.c
> >>> (log_noop_revs): The baton's po
Greg Stein wrote:
> Sure, the removal from the INSTALL file was rather aggressive, in
> hindsight.
>
> Thanks!
r1148652.
Arfrever Frehtes Taifersar Arahesis wrote:
> 2011-07-19 18:33:26 Julian Foad napisał(a):
> > - The Serf library has support for SSL encryption by relying on
> > - th
On Tue, Jul 19, 2011 at 19:53, Greg Stein wrote:
>...
> The only pending serf issue is my testing of a fix to memory blowup in
> ra_serf when somebody checks out a repository root (ie. 10's of
There appears to be a bug in my debug code, or the original code. The
night is done, but I will continue
49 matches
Mail list logo
