Hi,
Von: Neels J Hofmeyr [mailto:ne...@elego.de]
>
> On 08/29/2011 05:48 PM, C. Michael Pilato wrote:
> > No sweat. 'svn commit --include-externals' sounds like a fine plan.
>
> +1 and volunteering.
Great, thanks!
> So by default, *all* externals shall be skipped from commit (dir and file
>
Translation status report for trunk@r1163083
lang trans untrans fuzzy obs
--
de2078 157 327 252 UUoo
es2004 231 354 388 +++UU~
fr2185 50
On 08/26/2011 07:14 AM, Stefan Sperling wrote:
> cmpilato, does this significantly differ from what you've done for BDB?
> Will both backends have the same (or similar) behaviour if we use
> this design for FSFS?
Most of what you discuss in this proposal is related to the detailed
properties of th
On Fri, Aug 26, 2011 at 5:38 PM, Hyrum K Wright
wrote:
> After the much-ballyhooed RC1, I've re-rolled an RC2. You can fetch
> the proposed tarballs from here:
> http://people.apache.org/~hwright/svn/1.7.0-rc2/
>
> The magic rev is r1162132; please post signatures at the normal location:
> http
On 08/29/2011 06:15 PM, Neels J Hofmeyr wrote:
> - when a *pegged* external is passed as explicit target (and say even if
> --include-externals is passed), should we *still* refuse to commit it?
>
> I'd say [...] yes (thinking of avoiding
> inconsistent external state as seen with file externals,
On 08/29/2011 08:46 PM, C. Michael Pilato wrote:
>sne-wc-top (an empty wc)
> unversioned
> sne-wc-nested (a different empty wc from svn-wc-top)
> unversioned
>sne-wc-ext (a third, different empty wc, which is an
> externa
On Mon, Aug 29, 2011 at 04:45:18PM -0400, Mark Phippard wrote:
> Is anyone running the tests? We should have no shortage of committers that
> can provide a *nix signature.
They're still running here. I'll have sigs tomorrow morning (CEST).
> -Original Message-
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: maandag 29 augustus 2011 21:55
> To: Neels J Hofmeyr
> Cc: dev@subversion.apache.org
> Subject: Re: Recurse into same-repos externals at commit time.
>
> On 08/29/2011 02:47 PM, Neels J Hofmeyr wrote:
> >
> -Original Message-
> From: Neels J Hofmeyr [mailto:ne...@elego.de]
> Sent: maandag 29 augustus 2011 20:47
> To: dev@subversion.apache.org
> Subject: Re: Recurse into same-repos externals at commit time.
>
> On 08/29/2011 06:23 PM, C. Michael Pilato wrote:
> > On 08/29/2011 12:15 PM, Ne
Is anyone running the tests? We should have no shortage of committers that
can provide a *nix signature.
On Mon, Aug 29, 2011 at 9:09 AM, Hyrum K Wright
wrote:
> By my count, we're still lacking a *nix signature.
>
> -Hyrum
>
> On Fri, Aug 26, 2011 at 10:38 AM, Hyrum K Wright
> wrote:
> > Af
On 08/29/2011 02:47 PM, Neels J Hofmeyr wrote:
> On 08/29/2011 06:23 PM, C. Michael Pilato wrote:
>> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
>>> - when an external is passed as explicit target, still require
>>> --include-externals?
>>
>> No. Because we've recommended in the issue I referen
C. Michael Pilato wrote on Mon, Aug 29, 2011 at 14:46:40 -0400:
> On 08/29/2011 02:23 PM, Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Mon, Aug 29, 2011 at 12:23:34 -0400:
> >> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
> >>> If user wants to commit to a *pegged* external, user should ju
On 08/29/2011 06:23 PM, C. Michael Pilato wrote:
> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
>> - when an external is passed as explicit target, still require
>> --include-externals?
>
> No. Because we've recommended in the issue I referenced exactly this
> behavior as a workaround for this
On 08/29/2011 02:23 PM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Mon, Aug 29, 2011 at 12:23:34 -0400:
>> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
>>> If user wants to commit to a *pegged* external, user should just use a
>>> different, non-externals-ized checkout.
>>
>> AFAIK, we don
On Mon, Aug 29, 2011 at 09:08, Hyrum K Wright wrote:
> In an effort to make sure my problems with serf are well known, I'm
> posting this. I'm attempting to create a tag of a personal project,
> and get the following error (over https, with the 1.7.x branch):
>
> [[[
> $ svn cp $REPOS/hikehy/trun
C. Michael Pilato wrote on Mon, Aug 29, 2011 at 12:23:34 -0400:
> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
> > If user wants to commit to a *pegged* external, user should just use a
> > different, non-externals-ized checkout.
>
> AFAIK, we don't have the means to detect and prevent this acti
On Mon, Aug 29, 2011 at 08:04:09PM +0400, Danil Shopyrin wrote:
> Hi Stefan!
>
> On Mon, Aug 29, 2011 at 6:54 PM, Stefan Sperling wrote:
> > Any ideas about how to solve this without using successors?
> >
> > [[[
> > deleted_nodes = nodes which appear in LEFT_PATH@LEFT_REV but not in
> >
On Fri, Aug 26, 2011 at 8:10 PM, Neels J Hofmeyr wrote:
> found in branches/1.7.x/*
> by
> [[[
> + grep --exclude-dir=".svn" --exclude-dir=".libs" --exclude="*.o" -rn -i
> 'before.*1\.7' subversion | grep -v Binary
> [...]
> ./subversion/libsvn_wc/wc-metadata.sql:761: Before we release 1.7, thes
On Sun, Aug 28, 2011 at 03:46:03PM +0200, Stefan Fuhrmann wrote:
> >See
> >http://svn.apache.org/repos/asf/subversion/branches/fs-successor-ids/BRANCH-README
> >for what this is all about.
> But the assumptions in that file are actually not valid.
Which ones are invalid? Can you explain in detail
On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
> On 08/29/2011 05:48 PM, C. Michael Pilato wrote:
>> No sweat. 'svn commit --include-externals' sounds like a fine plan.
>
> +1 and volunteering.
>
> So by default, *all* externals shall be skipped from commit (dir and file
> externals alike).
>
>
On 08/29/2011 05:48 PM, C. Michael Pilato wrote:
> No sweat. 'svn commit --include-externals' sounds like a fine plan.
+1 and volunteering.
So by default, *all* externals shall be skipped from commit (dir and file
externals alike).
When --include-externals is passed to 'svn commit', *all* exter
Hi Stefan!
On Mon, Aug 29, 2011 at 6:54 PM, Stefan Sperling wrote:
> Any ideas about how to solve this without using successors?
>
> [[[
> deleted_nodes = nodes which appear in LEFT_PATH@LEFT_REV but not in
> RIGHT_PATH@RIGHT_REV
> added_nodes = nodes which appear in RIGHT_PATH
On Sat, Aug 27, 2011 at 02:15:31AM +0300, Daniel Shahaf wrote:
> Add it as sibling of 'structure' on the branch? That's its ultimate home.
Fair enough.
> > - cache can be regenerated on demand
>
> Regenerated *offline*, right? ie, if the cache is lost it can be
> derived from the revision fil
On 08/29/2011 11:45 AM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: C. Michael Pilato [mailto:cmpil...@collab.net]
>> Sent: maandag 29 augustus 2011 17:40
>> To: Neels J Hofmeyr
>> Cc: Subversion Development
>> Subject: Recurse into same-repos externals at commit time. (was: [P
> -Original Message-
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: maandag 29 augustus 2011 17:40
> To: Neels J Hofmeyr
> Cc: Subversion Development
> Subject: Recurse into same-repos externals at commit time. (was: [PATCH]
> don't recursively-commit pegged file externals
On 08/29/2011 11:33 AM, C. Michael Pilato wrote:
>> ### It is also debatable if we should also skip *un*pegged file externals
>> from recursion, just like we do with dir externals.
>
> I tend to lobby for treatment of file externals more consistently with
> directory externals. But now that our c
On 08/29/2011 11:21 AM, Neels J Hofmeyr wrote:
> Anyone up for discussing the two '###'-comments in this patch's log message?
> I think this patch is necessary, but feel free to discuss it to smithereens.
> I'd say +1 for both '###'-comments, for consistency with dir externals.
[...]
> ### It is
Anyone up for discussing the two '###'-comments in this patch's log message?
I think this patch is necessary, but feel free to discuss it to smithereens.
I'd say +1 for both '###'-comments, for consistency with dir externals.
Omit pegged file externals (that have a specific rev) from recursive comm
On Fri, Aug 26, 2011 at 08:59:21AM -0400, C. Michael Pilato wrote:
> On 08/26/2011 08:51 AM, Ivan Zhakov wrote:
> > Mike, thanks for the answer, but I still don't understand how
> > successor ID information could help us with move handling?
>
> (Honestly, I don't either. I was taking Stefan's wor
http://subversion.tigris.org/issues/show_bug.cgi?id=3590 documents some of
the history of this action (copy from a foreign repository). I have no idea
how 1.7 behaves in this same scenario, though I don't recall anyone
intentionally targeting this functionality.
That said, as it was me that filed
By my count, we're still lacking a *nix signature.
-Hyrum
On Fri, Aug 26, 2011 at 10:38 AM, Hyrum K Wright
wrote:
> After the much-ballyhooed RC1, I've re-rolled an RC2. You can fetch
> the proposed tarballs from here:
> http://people.apache.org/~hwright/svn/1.7.0-rc2/
>
> The magic rev is r11
In an effort to make sure my problems with serf are well known, I'm
posting this. I'm attempting to create a tag of a personal project,
and get the following error (over https, with the 1.7.x branch):
[[[
$ svn cp $REPOS/hikehy/trunk $REPOS/hikehy/releases/4.0.0
subversion/svn/copy-cmd.c:134: (ap
On Fri, Aug 26, 2011 at 05:27:16PM +0100, Julian Foad wrote:
> I (Julian Foad) wrote:
> > I was just cleaning up this editor, stripping out this "target" path
> > completely, so that it would simply pass relative paths out to the diff
> > callbacks and to the notification functions. The merge code
On Fri, Aug 26, 2011 at 04:00:15PM +0300, Daniel Shahaf wrote:
> I tested with rc1, and now with trunk, and in both cases a tree conflict
> is reported on the node that was modified on branch and
> modified+moved-away on trunk.
>
> >From Stefan's commit messages I expected the issue to be fixed on
Hi,
(This is a slightly enhanced repost.)
I'm using latest build of SharpSVN against SVN 1.7.
I'm using SvnClient.Info() which maps to svn_client_info_3().
It seems that the svn_client_info_receiver2_t parameter abspath_or_url
shows inconsistent behavior when calling svn_client_info_3 on a wor
The 1.6 book has the same Note text, as does
http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.copy.html - so at
least it hasn't been documented any differently in that time. (So it
at least appears that cross-repo cherry-picking isn't an
intentionally-supported use case...)
On Mon, Aug 22, 20
36 matches
Mail list logo
