On my Linux machine svnserve with threading and revprop caching causes
authz_tests 7 to FAIL:
$ subversion/svnserve/svnserve --cache-revprops yes -Tdr
subversion/tests/cmdline
and
$ ./authz_tests.py --url=svn://localhost 7
gives:
2012-04-19 09:56:31 [WARNING] CWD:
/home/pm/sw/subversion/obj/
Hi all,
After having a closer look at merge and discussing it
with Julian on IRC, there seems to be no silver bullet.
However, we identified a few things that could be changed
and set of constellations that make merge harder than
it needs to be.
For the first, there will be another post soon. Th
On 19.04.2012 12:48, Stefan Fuhrmann wrote:
> Also, the merges that happened on the source branch
> from a different location than the target branch are
> of no interest for the policy checkers. E.g.:
>
> r20: merge r19 from ^/sub-branch to ^/branch
> txn: merge r10-20 from ^/branch to ^/
Stefan,
What I understand you're saying is:
Here are some bits of merging policy, which users quite commonly may wish to
enforce for some of their branches. And in particular these are bits of policy
that could perhaps be enforced by means of hook scripts. If we help to create
a bunch of suc
On Thu, Apr 19, 2012 at 12:48 PM, Stefan Fuhrmann
wrote:
> Hi all,
>
> After having a closer look at merge and discussing it
> with Julian on IRC, there seems to be no silver bullet.
> However, we identified a few things that could be changed
> and set of constellations that make merge harder than
Johan Corveleyn wrote:
> I haven't read your mail in detail yet, but [...] propgetting
> ('svnlook propget') every changed file during pre-commit can be very
> expensive.
[...]
> The problem is mainly that 'svnlook propget' doesn't support recursive
> propgetting, nor getting all props from the ent
On Thu, Apr 19, 2012 at 12:48:44PM +0200, Stefan Fuhrmann wrote:
> Hi all,
>
> After having a closer look at merge and discussing it
> with Julian on IRC, there seems to be no silver bullet.
> However, we identified a few things that could be changed
> and set of constellations that make merge har
I have no objection to coming up with some hook scripts to help
enforce merge policies. I recall seeing this project on users@:
http://sourceforge.net/apps/mediawiki/svnhook/index.php?title=Main_Page
It adds the ability to block subtree merges by rejecting commits that
add mergeinfo below the ro
I've been poking around import, and I discovered this snippet of
decade-old code:
/* The repository doesn't know about the reserved administrative
directory. */
if (new_entries->nelts
/* What's this, what's this? This assignment is here because we
use the value to construc
On Thu, Apr 19, 2012 at 2:17 PM, Julian Foad wrote:
> Johan Corveleyn wrote:
>> I haven't read your mail in detail yet, but [...] propgetting
>> ('svnlook propget') every changed file during pre-commit can be very
>> expensive.
> [...]
>> The problem is mainly that 'svnlook propget' doesn't suppor
Yes, I agree. If merge handles moves, and if merging between branch
and trunk doesn't require arguments and reintegrate, then it would work
in enough cases to make people comfortable with the review-and-merge
workflow.
It does seem that moves and renames cause a high percentage of user
comp
On Thu, Apr 19, 2012 at 9:26 AM, Mark Phippard wrote:
> I have no objection to coming up with some hook scripts to help
> enforce merge policies. I recall seeing this project on users@:
>
> http://sourceforge.net/apps/mediawiki/svnhook/index.php?title=Main_Page
>
> It adds the ability to block su
On Thu, Apr 19, 2012 at 8:51 AM, Andy Singleton wrote:
> Yes, I agree. If merge handles moves, and if merging between branch and
> trunk doesn't require arguments and reintegrate, then it would work in
> enough cases to make people comfortable with the review-and-merge workflow.
>
> It does seem
Stefan Fuhrmann wrote:
> The following pre-commit scripts / policies would be useful.
>
> * Common parts [not a policy]
> We first check whether the commit contains a changed
> svn:merge-info property. This limits the performance
> impact on non-merge commits and we need to identify
> all
On Thu, Apr 19, 2012 at 6:48 AM, Stefan Fuhrmann
wrote:
> Hi all,
>
> After having a closer look at merge and discussing it
> with Julian on IRC, there seems to be no silver bullet.
> However, we identified a few things that could be changed
> and set of constellations that make merge harder than
On Thu, Apr 19, 2012 at 08:59:58AM -0500, Hyrum K Wright wrote:
> While I've not done any experiments, it feel like it might be possible
> to heuristically detect some (but not all) moves by looking at copies,
> and asking if the source was deleted in the same revision. There are
> probably all ki
Mark Phippard wrote:
> My concern is any link between these scripts and our merge code. It
> sounds like the plan would be to create these policies and then come
> up with a newmerge command that does not support any of the features
> these policies block?
No, that's not this community's plan.
On Apr 19, 2012 11:02 AM, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_fs/fs-loader.c Thu Apr 19 15:02:17
2012
>...
> + if (kind == svn_node_dir)
> +{
> + svn_error_clear(err);
> + *fs_type = apr_pstrdup(pool, SVN_FS_TYPE_BDB);
> + return SVN_NO_ERRO
Greg Stein wrote on Thu, Apr 19, 2012 at 11:17:19 -0400:
> Won't this error appear in the response? In which case, you're leaking a
> server path to the client.
No, the code just below the mail's diff context sanitizes the error.
On 04/19/2012 09:26 AM, Hyrum K Wright wrote:
> I've been poking around import, and I discovered this snippet of
> decade-old code:
>
> /* The repository doesn't know about the reserved administrative
> directory. */
> if (new_entries->nelts
> /* What's this, what's this? This assi
On Thu, Apr 19, 2012 at 10:29 AM, C. Michael Pilato wrote:
> On 04/19/2012 09:26 AM, Hyrum K Wright wrote:
>> I've been poking around import, and I discovered this snippet of
>> decade-old code:
>>
>> /* The repository doesn't know about the reserved administrative
>> directory. */
>> if
Greg Stein writes:
> On Apr 19, 2012 11:02 AM, wrote:
>>...
>> +++ subversion/trunk/subversion/libsvn_fs/fs-loader.c Thu Apr 19 15:02:17
> 2012
>>...
>> + if (kind == svn_node_dir)
>> +{
>> + svn_error_clear(err);
>> + *fs_type = apr_pstrdup(pool, SVN_FS_TYPE_BDB);
Philip Martin writes:
> I moved that code without considering that. The documentation
> explicitly states that the result is allocated in pool but I think we
> can change that. It also allows me to rename pool to scratch_pool. I
> suppose there is a theoretical problem if libsvn_fs is dynamica
On 19.04.2012 16:56, Julian Foad wrote:
> To get symmetric behaviour, the problem is it's freakin' hard to untangle the
> subtree support and the mixed-rev support and the missing-subtree support and
> everything from the basic merge algorithm outline, in the existing code. And
> the problem i
On 19.04.2012 16:02, Paul Burba wrote:
> Just one thing I'm wondering about:
>> This should give us enough time to improve
>> the merge logic inside the SVN libs.
> Which improvements are these exactly? What is documented in
> http://wiki.apache.org/subversion/SymmetricMerge?action=show&redirect=S
Branko Čibej wrote:
> Julian Foad wrote:
>> To get symmetric behaviour, the problem is it's freakin' hard to
>> untangle the subtree support and the mixed-rev support and the
>> missing-subtree support and everything from the basic merge algorithm
>> outline, in the existing code. And the pro
On 19.04.2012 18:57, Julian Foad wrote:
> Branko Čibej wrote:
>
>> Julian Foad wrote:
>>> To get symmetric behaviour, the problem is it's freakin' hard to
>>> untangle the subtree support and the mixed-rev support and the
>>> missing-subtree support and everything from the basic merge algorithm
- Original Message -
> From: Branko Čibej
> To: dev@subversion.apache.org
> Cc:
> Sent: Thursday, 19 April 2012, 18:10
> Subject: Re: Merge policies
>
> On 19.04.2012 18:57, Julian Foad wrote:
>> Branko Čibej wrote:
>>
>>> Julian Foad wrote:
To get symmetric behaviour, the
On 04/19/2012 11:44 AM, Hyrum K Wright wrote:
> This is a good description of the rationale, and I agree that
> committing .svn directories is probably a bad idea. It's just that
> the check quoted above feels woefully single-minded: "Check the
> immediate precursor to the import target, and rejec
On Apr 19, 2012, at 8:38 AM, Stefan Sperling wrote:
> On Thu, Apr 19, 2012 at 12:48:44PM +0200, Stefan Fuhrmann wrote:
>> Hi all,
>>
>> After having a closer look at merge and discussing it
>> with Julian on IRC, there seems to be no silver bullet.
>> However, we identified a few things that cou
C. Michael Pilato wrote:
> I guess I don't see this as "whack-a-mole with 'svn
> import'". 'svn import' is treated uniquely because it is
> genuinely unique -- no other Subversion operation tries to
> directly replicate unversioned data in the repository without
> first "staging it" in the worki
On Apr 19, 2012, at 1:36 PM, Trent Nelson wrote:
>
> On Apr 19, 2012, at 8:38 AM, Stefan Sperling wrote:
>
>> On Thu, Apr 19, 2012 at 12:48:44PM +0200, Stefan Fuhrmann wrote:
>>> Hi all,
>>>
>>> After having a closer look at merge and discussing it
>>> with Julian on IRC, there seems to be no
On Thu, Apr 19, 2012 at 12:57 PM, Julian Foad
wrote:
> Branko Čibej wrote:
>
>> Julian Foad wrote:
>>> To get symmetric behaviour, the problem is it's freakin' hard to
>>> untangle the subtree support and the mixed-rev support and the
>>> missing-subtree support and everything from the basic mer
On Apr 19, 2012 12:18 PM, "Philip Martin"
wrote:
>
> Greg Stein writes:
>
> > On Apr 19, 2012 11:02 AM, wrote:
> >>...
> >> +++ subversion/trunk/subversion/libsvn_fs/fs-loader.c Thu Apr 19
15:02:17
> > 2012
> >>...
> >> + if (kind == svn_node_dir)
> >> +{
> >> + svn_error_c
Greg Stein writes:
> Do we ever unload the modules? I know mod_dav_svn.so can get unloaded. But
> FS modules?
Well, I suppose if mod_dav_svn gets unloaded then libsvn_fs will be
unloaded as well. But anything unloading libsvn_fs is unlikely to want
to access the memory returned by svn_fs_type.
I've been splitting between been a svn baby/trying to swim into svn
code and reading the wiki plus mails regarding symmetric merge.
(Please be patient if I'll bump into some inherent beginner
stupidities, I'm still into the crash course phase).
> 1. Find the latest rev of A synced to B and of B s
36 matches
Mail list logo
