On Wed, Nov 25, 2009 at 10:06:44AM -0800, Andreas Krey wrote:
> > > real tagging
> > What did you understand by "real tagging" ?
>
> Like 'tagging that is not simulated by branches that we need to
> configure readonly'?
>
> Like having some protection against accidentally switching from
> trunk/subdir to branch/X instead of branch/X/subdir?
That's the price of flexibility -- users can make mistakes.
A lot of software (basically anything more complicated than "Hello
World") has this problem.
Can you suggest a suitable default target URL for the generic case
where people use an arbitrary repository structure and software
development process? If so, we could fix this :)
I'd rather have Subversion support many, many ways of organising the
software development process than making choices in advance for
Subversion's users which end up limiting flexibility.
I think the usability/flexibility ratio of Subversion is still quite
good compared to other tools, except maybe Mercurial which has a very
sweet usability/flexibility ratio.
> 1) Because of the "we don't really have branches" you need to type a
> lot of URLs when doing branches and merges,
That's not true in 1.6.x anymore, you can use ^ to refer to the
repository root. I rarely type URLs these days.
> 2) svn makes a lot of serial HTTP requests which isn't exactly helpful
> or fast when you aren't within throwing distance from your server
> (read: DSL (svn ls takes 0.4s) or GPRS (svn ls takes twelve seconds)).
Yes, HTTP is very slow.
You could try svn:// or svn+ssh:// if HTTP is too slow.
But tuning the network protocols to do fewer round-trips could be
something worth looking into.
> Acually, and as far as I understand the docs, keeping a branch in sync
> with the trunk by repeatedd merging is doable with svn (1.5ff), only
> the backmerge into trunk needs an --reintegrate, and after that the
> branch is effectively dead, as the mergeinfo is garbled by design at
> that point.
It's not a design problem, and the design isn't garbled because of this.
It's something that follows from the design and is expected.
In short: The branch is "dead" because the changes you made in your
branch revisions /branch:rA,B,C,etc. are not all contained in the reintegrate
commit to trunk, rX. Subversion does not know that, semantically, /trunk:rX
is the same as /branch:rA,B,C, etc. and already contained in the branch.
The next sync-up merge of branch with trunk would try to pull /trunk:rX,
and any conflict resolution done during the reintegrate merge would cause
conflicts during this catch-up merge. But you can do a single --record-only
merge of /trunk:rX to the branch, after which you can keep using your branch
without having a gap in its history.
We tell people to delete the branch after reintegrate and re-branch
if they still need the branch because that is much simpler to understand
and explain, and because in the majority of cases it's not less correct
than doing the record-only merge. But, if you prefer, you can use a
record-only merge instead. There were attempts to automate the record-only
merge IIRC, but AFAIK this turned out to be tricky to implement.
But again, this is a result of a very flexible design, maybe too flexible.
E.g. try merging changes made to a single file affected by a revision,
and later merging other changes from another file affected by that same
revision, in other version control systems. I bet your merges won't be
tracked (i.e. recorded in meta-data rather than commit log messages).
Granted, people rarely do this in practice (unless they are heavy
cherry-pickers), but it was one of the design goals of merge-tracking.
And the design lives up to that goal. Again, people can make lots of
mistakes doing merges like this and mess up mergeinfo, which can cause
user frustration down the road. But if used right, it works beautifully.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424386
Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-11-25 20:39:02 CET