On Wed, 25 Nov 2009 20:38:07 +0000, Stefan Sperling wrote:
> On Wed, Nov 25, 2009 at 10:06:44AM -0800, Andreas Krey wrote:
...
> > 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 :)
It would be helpful (and maybe it does even exist), but probably
too complicated to implement, that the server admin could create
rules that svn switch (without a --force) would only substitute
/trunk/ for /branches/*/ or /tags/*/ and vice versa, or other
rules depending on server layout. But then I think that is
a lot of work for a little effect. (Wouldn't be surprised when
tortoisesvn does something like that.)
...
> > 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.
I know. Progress is trickling in. I'd like (and expect)
'svn switch ../branches/mybranch' to do the obvious instead
of giving me 'not a working copy there'.
Hmm, perhaps ^../branches/bla as a shortcut relative to the
URL of the current directory (as of svn info)?
(^rel as opposed to ^/abs, note the '/' after the '^'.)
...
> Yes, HTTP is very slow.
> You could try svn:// or svn+ssh:// if HTTP is too slow.
svn:// is out of the question (some authentication issue,
according to server admins). svn+ssh may be of help, depending
on how auth and access control is done (as least for me).
...
> > 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 the mergeinfo that does not reflect the state of affairs, and
the design of svn:mergeinfo apparently does not support full
merge tracking.
> It's something that follows from the design and is expected.
Yes and no. We came from cvsnt, and they did support full bidir
merges between trunk and a branch. Ok, they broke that later,
but our expectations on svn merge tracking were higher than
what svn delivers so far.
> 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.
Or, in other words, the svn:mergeinfo cannot store all merge information
properly. The problem is that the mergeinfos on trunk and on the branch
don't tell *when* the respective merges have been made, but the decision
how to merge depends on this information.
...
> But again, this is a result of a very flexible design, maybe too flexible.
It's obviously not flexible enough, otherwise reflexive merge should
pose no problem?
> 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).
cvsnt: Works (if for the simple reason that there are no global
revisions). git: They refuse to merge anything less than the whole
tree which makes tracking (and storing in general) a lot more easier.
Actually the latter is the reason why I don't push the use of git
for us; I've done too many single-file merges in cvsnt; on the other
hand there is no reason why files or directories should be the
mergeable unit.
svn: Well, why is the mergeinfo on the directory instead of on the
individual files? Information about merges is actually ancestry
information, as the ancestry graph of a file determines how and
what to merge. (git does that on a whole-tree basis.) And a file
needs to know its predecessor anyway; in case of copies that isn't
simply the last changed revision of the same name. To track merges
one would simple need to make place for a second pointer-to-ancestor,
and the one could trivially compute the ancestor graph, and then
go clone the actual merge algos from git. :-) (Ok, handling renames
and especially copies are still not quite obvious.)
I really wonder why the merge info is not stored where the copy info is.
For special marvels: Note that a single revision may modify the
trunk and a branch. Not very usual, but possible.
Doing it with svn:mergeinfo has a single advantage: You have a place in
the sandbox where you can store that information until it is committed.
...
> user frustration down the road. But if used right, it works beautifully.
You may notice that your definition of 'right' is a bit restricted;
at the moment I have the problem that I need to think very hard
before copying branching models I'm used to from git (or clearcase,
for that matter) for fear of having the merge tracking doing the
unexpected thing at the wrong time.
Question: What will sandboxes on branch/X do if I do
merge --reintegrate branch/X => trunk
rm branch/X
copy trunk branch/X
Will local modification survive such an act and be committable?
Andreas
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424430
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 22:57:25 CET