On Wed, Sep 9, 2009 at 11:46 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> I was thinking today about how Subversion offers all this flexibility in
> terms of branch creation ("it's just a copy of a directory!") but sometimes
> at the cost of some benefits you might otherwise get from a first-class
> branch object.
>
> Could a really, really simple solution help here? What if Subversion
> recognized a directory property (say, "svn:branch-root") as an indicator
> that that directory is the root of a branch (where by "branch", I mean "line
> of development", which includes trunk and tags)? Benefits could include:
>
> * the fact that the property would naturally get set on copies of that
> directory, ensuring that branches of the directory are annotated as
> such.
>
> * helping the client discourage commits of subsets of a branch.
>
> * helping the client warn users about merging at anything less than
> the branch level.
Mike,
(Sorry for the late reply, this came in while I was on vacation and I
missed it*)
Those last two bullets are the same thing no?
> * helping tools like ViewVC and Trac identify branches, and add UI
> goodness accordingly.
>
> It sounds too simple to be truly useful. What do others think?
Anyway, here are some thoughts on this topic, not so much related to
whether a branch root identifier is useful or not, but rather what the
implications are for merge tracking.
Often when discussing the problems with svn:mergeinfo people say,
"well let's not allow that", where "that" is a subtree merge, a merge
to a mixed-rev WC, a shallow merge, a merge into a shallow WC, a merge
to a target with switched subtrees, and/or a merge in which the user
isn't authorized to a subtree in the merge source and/or the merge
target.
Speaking for myself, I have little reason to do any of these things,
except the rare subtree merge, while working with the Subversion
repository. Taken individually, it is likely that only small
minorities of our users do any one of these, but I'm confident that a
majority have need to do at least one of these on occasion. Further,
Subversion has always allowed these (at least as long as the related
feature (e.g. --depth) has existed.
Now you're not saying we should disallow these practices, but rather
warn against them and instead implicitly (or explicitly) recommend
what amounts to best practices for merging. This is great, since
currently merge tracking works quite well if one only ever merges to
the root of a branch. But short of prohibiting these other
problematic use cases, I don't know that this proposal helps very
much, since we still need to make merge tracking do the right thing.
Paul
* So now I am replying on *your* vacation :-P
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2392974
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2401705
Received on 2009-09-29 18:41:49 CEST