On Fri, Apr 20, 2012 at 10:52 PM, Stefan Fuhrmann eq...@web.de wrote:
Am 19.04.2012 14:03, schrieb Johan Corveleyn:
[snip]
I haven't read your mail in detail yet, but just a note in passing: in
my experience (with a 1.5 server with FSFS-on-NFS backend) propgetting
('svnlook propget') every
Johan Corveleyn wrote on Wed, May 02, 2012 at 12:20:35 +0200:
On Fri, Apr 20, 2012 at 10:52 PM, Stefan Fuhrmann eq...@web.de wrote:
Am 19.04.2012 14:03, schrieb Johan Corveleyn:
[snip]
I haven't read your mail in detail yet, but just a note in passing: in
my experience (with a 1.5
Johan Corveleyn jcor...@gmail.com writes:
On Fri, Apr 20, 2012 at 10:52 PM, Stefan Fuhrmann eq...@web.de wrote:
Am 19.04.2012 14:03, schrieb Johan Corveleyn:
- maybe propgetting through one of the bindings is much faster than
through svnlook, and you intend for admins to set this up with some
don't have the cycles to work on this myself, but I just
wanted to mention this as an important aspect if more and more tools
are going to validate properties in pre-commit hooks (like for
enforcing merge policies).
--
Johan
On Thu, Apr 19, 2012 at 12:48 PM, Stefan Fuhrmann
stefanfuhrm...@alice-dsl.de wrote:
[snip]
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
On Wed, May 2, 2012 at 11:24 AM, Johan Corveleyn jcor...@gmail.com wrote:
On Thu, Apr 19, 2012 at 12:48 PM, Stefan Fuhrmann
stefanfuhrm...@alice-dsl.de wrote:
[snip]
The following pre-commit scripts / policies would be useful.
* Common parts [not a policy]
We first check whether the
Paul Burba wrote on Wed, May 02, 2012 at 11:42:18 -0400:
And for some reason the spacing of ASCII diagram I posted in [2] is
wrong on svn.haxx.se, it's a lot easier to understand here:
svn.haxx.se gets the spacing correctly in the HTML source view, just not
in the rendered view.
(Also, the
Am 24.04.2012 16:32, schrieb Julian Foad:
Paul Burba wrote:
On Fri, Apr 20, 2012 at 6:17 AM, Julian Foad wrote:
I see there's already a brief statement about sparse WCs too:
http://svn.apache.org/repos/asf/subversion/trunk/notes/merge-tracking/func-spec.html#sparse-checkouts.
I'm not clear
Paul Burba wrote:
On Fri, Apr 20, 2012 at 6:17 AM, Julian Foad wrote:
I see there's already a brief statement about sparse WCs too:
http://svn.apache.org/repos/asf/subversion/trunk/notes/merge-tracking/func-spec.html#sparse-checkouts.
I'm not clear how the whole 'depth' thing works, though,
Paul Burba wrote on 2012-04-23:
Do you have a pointer to some details about how a mixed-rev target WC
is handled?
(Julian, apologies if most of this is old-hat for you, I'm writing as
much for the newly involved folks as I am for you)
Hi Paul. Thanks for this detailed exposition.
At
On Fri, Apr 20, 2012 at 5:07 PM, Paul Burba ptbu...@gmail.com wrote:
On Fri, Apr 20, 2012 at 6:17 AM, Julian Foad julianf...@btopenworld.com
wrote:
Paul Burba wrote:
On Thu, Apr 19, 2012 at 12:57 PM, Julian Foad wrote:
Branko Čibej wrote:
By the way, I'm all for removing support for
Branko Čibej wrote:
On 20.04.2012 23:45, Stefan Fuhrmann wrote:
We could even be more permissive: as long as the merge
does not cross switch boundaries (switched / non-
switched or switched to different URL) as may allow
the merge.
This could be a somewhat typical use-case for people
using
On 20.04.2012 23:45, Stefan Fuhrmann wrote:
We could even be more permissive: as long as the merge
does not cross switch boundaries (switched / non-
switched or switched to different URL) as may allow
the merge.
This could be a somewhat typical use-case for people
using switched WCs. I
Paul Burba wrote:
On Thu, Apr 19, 2012 at 12:57 PM, Julian Foad wrote:
Branko Čibej wrote:
By the way, I'm all for removing support for merging into
mixed-revision
and/or switched-subtree working copies. There's too much room for
unexpected results in these cases.
I don't
Julian Foad wrote:
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
Am 19.04.2012 14:03, schrieb Johan Corveleyn:
On Thu, Apr 19, 2012 at 12:48 PM, Stefan Fuhrmann
stefanfuhrm...@alice-dsl.de 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
On Fri, Apr 20, 2012 at 6:17 AM, Julian Foad julianf...@btopenworld.com wrote:
Paul Burba wrote:
On Thu, Apr 19, 2012 at 12:57 PM, Julian Foad wrote:
Branko Čibej wrote:
By the way, I'm all for removing support for merging into
mixed-revision
and/or switched-subtree working copies.
Am 19.04.2012 18:57, schrieb Julian Foad:
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,
Am 19.04.2012 16:02, schrieb Julian Foad:
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
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.
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 ^/trunk
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
On Thu, Apr 19, 2012 at 12:48 PM, Stefan Fuhrmann
stefanfuhrm...@alice-dsl.de 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
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 entire
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 harder
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
On Thu, Apr 19, 2012 at 2:17 PM, Julian Foad julianf...@btopenworld.com 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
detection, without move tracking.
On 4/19/2012 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
On Thu, Apr 19, 2012 at 9:26 AM, Mark Phippard markp...@gmail.com 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
On Thu, Apr 19, 2012 at 8:51 AM, Andy Singleton a...@assembla.com 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.
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
that her life harder than
necessary.
Hi Stefan,
No objections to developing a set of hook scripts to optionally
enforce different merge policies; that seems completely reasonable
(I'm not expressing an opinion one way or the other regarding the
details of the particular scripts).
Just one thing I'm
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 kinds
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. I
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 is
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
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 problem is
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
outline,
- Original Message -
From: Branko Čibej br...@apache.org
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
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 could be
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 silver bullet.
On Thu, Apr 19, 2012 at 12:57 PM, Julian Foad
julianf...@btopenworld.com 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
42 matches
Mail list logo
