On Mon, Apr 05, 2010 at 04:14:21PM +0200, Martin Hauner wrote:
> Simplicity... actually I think subversion could or should be even
> simpler. It may be easy from our point of view around here but when
> I see how people use it, it still seems to be too complicated. One
> has to draw a line at some level of knowledge, sure, but think we
> could improve here.
>
> Referring to my merging example below, It is astonishing difficult
> to explain the svn:merginfo property and why you have to update
> after each commit. From a user perspective (which are still
> programmers but don't know very much of subversion) this is a "what
> the heck" issue.
>
> The /trunk/branches/tags convention works but it happens from time
> to time that people get the copy target wrong and copy folders into
> itself or something like this. Would be nice if subversion could
> catch this.
>
> Just an idea here, what about a convention enforcing wrapper around
> the svn client api which would prevent wrong copies based on the
> convention rules.(however one decides that)?
Your concerns are very valid.
At the meeting we also briefly discussed that svn makes it too easy
for users to shoot themselves in the foot. This is the price of high
flexibility. People can do things that don't make any sense (e.g.
svn copy ^/branches/trunk ^/branches/someotherbranch/mybranch), and
svn will not warn or complain.
The same goes for merging. E.g. DCVS tools simply don't have the concept
of doing tracked subtree merges (so merging is always damn easy and even
ruby on rails programmers get it ;), nor do they have the concept of mixed
revision working copies. But svn does support these concepts and they
add a lot of complexity. E.g. users end up doing subtree merges by mistake,
creating mergeinfo all over the place. They don't realise that the normal
use case is to have mergeinfo only on the branch root, and not doing any
subtree merges. They notice all the mergeinfo and do not understand
where it is coming from. They end up treating svn mergeinfo as black magic,
something they cannot control, just because they don't realise they're
making abundant use of a feature which was meant to be used in very
specific cases only.
An idea we're playing with to mitigate this problem is having designated
properties in the svn: namespace which allow users to tell svn what their
branching/merging strategy is. E.g. by setting a special property on the
branch root you could tell svn things like "my branch should only do sync
merges from trunk, cherry picking is not allowed from trunk. Cherry
picking is allowed from my bugfix branch, however. Also do not allow
subtree merges into this branch.", and svn would then try to enforce this.
So once the merge gurus have configured the policy, users who don't
fully grok the concepts cannot make a mess of it.
> I think subversion needs to improve on performance. I know that
> WC-NG will hopefully help here but I think it should be listed
> explicitly.
It will definitely help, not just hopefully.
People have done benchmarks already:
http://svn.haxx.se/dev/archive-2010-02/0457.shtml
http://svn.haxx.se/dev/archive-2010-02/0239.shtml
http://svn.haxx.se/dev/archive-2010-02/0241.shtml
> In case of merging (mostly cherry picking from trunk to live and
> next release branches, merge tracking is nice BUT svn:merginfo on
> the root folder kills it again. After each merge I have to update
> again (ie. wait another few minutes) before I'm able to commit
> again.
So mergeinfo kills it because it takes a long time to update?
How is this any different from the performance problem you mentioned,
and what has it got to do with mergeinfo?
Or do you generally oppose the idea of storing merge information
in svn: properties? If so, were else would you store it?
Thanks,
Stefan
Received on 2010-04-05 17:07:20 CEST