On Wed, Nov 25, 2009 at 10:56:17PM +0100, Andreas Krey wrote:
> 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.)
You mean like an optional list switch destinations which provide svn
with knowledge about "good" switches? And any other switch would
produce a warning or an error?
<imaginary feature, this does not exist>
Imagine the following:
$ tail -n 5 ~/.subversion/config
# invalid-switch-target can be set to 'warn' or 'error'
invalid-switch-target = error
[switch-targets]
^branches/[^/]+$
^trunk$
$ svn switch ^/branches/mybranch/some/subdir
svn: error: '^/branches/mybranch/some/subdir' is not in the 'switch-targets' list
$
Something like that should be easy to implement as a client-side
configuration option. Enforcing it from the server side would
probably be impossible.
If needed, valid switch-targets could also be configured on a per-server
basis in the ~/.subversion/servers file, rather than the
~/.subversion/config file.
Would something like this be useful?
</imaginary feature, this does not exist>
> ...
> > > 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'.
What do you think is obvious?
Do you mean that svn should get the URL from the working copy
path you passed to it, which lives in directory `pwd`/../branches/mybranch?
> Hmm, perhaps ^../branches/bla as a shortcut relative to the
> URL of the current directory (as of svn info)?
I don't see what you want to achieve here.
You're still typing "branches/bla"?
I guess, syntactically, something like ^. could be used,
so that e.g.
svn ls ^.
means "list the content of the current directory's URL".
And also ^.. meaning "URL of the parent directory".
But what problem do you really want to solve by adding more of such syntax?
> (^rel as opposed to ^/abs, note the '/' after the '^'.)
The current syntax is "^/" referring to the repository root.
> > > 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.
Any other expectations than not having to carry out a --record-only
merge to get a reintegrated branch to soak up changes from trunk again?
> > 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.
How exactly would knowing when something was added to mergeinfo solve
this problem?
> > 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?
If there wasn't a problem with automatic reflective merges they would
already be implemented. Reflective merges are possible, just not
automatically handled.
I'd have to dig up old discussion from before 1.5.0 release to find
out what the problem with making it happen automatically really was though.
> > 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.
Yes, git has a simpler model, they merge either everything or nothing.
They also support cherry picking but it's not tracked.
> 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?
It can be on files, not only on directories.
If you have lots of files (and subdirectories) with mergeinfo on them
performance will drop, because Subversion has to work out which
path/revision touples were merged, for every element with mergeinfo on it.
That's why most people only have mergeinfo at the branch root,
and for many cases that's sufficient.
That's a big problem with the design IMO, it doesn't scale well.
The performance problem is exacerbated by lots of network round-trips
that happen while the client is calculating mergeinfo.
> 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
This is true for git but not for Subversion.
I see how merging in theory affects ancestry, but it does not
affect the concept of ancestry that Subversion uses.
Ancestry in Subversion is defined by things like parent revisions
and copyfrom information. Merging is something that applies edits
or tree changes made to one subtree of the repository to another
subtree of the repository. It does not affect ancestry, except that
it can create copyfrom information (but I think the way copies are
merged is wrong, the copyfrom information should point to the
corresponding copy source within the merge target, not to the copy
source in the merge source).
> 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.
What other information would this copyfrom-like mergeinfo provide
than what svn:mergeinfo provides today? Even copyfrom information
is stored as a single path:revision pair.
> > 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?
Yes, sure, as long as people don't update between the rm and the copy.
If they do that, they'll get a "target path does not exist" error.
But as soon as the branch exists again, they're good to go.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424443
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-26 00:02:31 CET