Stefan Sperling wrote:
> On Wed, Sep 09, 2009 at 07:24:40PM +0200, Branko Cibej wrote:
>
>> That you then need an "svn branch" command to differentiate between
>> ordinary copies and actual branches, because you can't just always
>> blindly assume that a directory copy is in fact intended to be a branch.
>>
>
> Don't fear proliferation of subcommands, we can simply add a new
> --branch option to svn copy.
>
> (I would honestly prefer a new subcommand but most people don't seem
> to like them...)
>
(I also have a nasty suspicion that the "quick and simple" would soon
turn out to be neither quick nor simple, with ramifications extending
into move/rename, merge tracking, client-side presentation, and probably
a number of areas I can't even think of now. I'm very suspicious of
quick and simple solutions to problems that are inherently complex.)
>> Or even better, first-class branches in the repo. Makes for less user
>> confusion as to what's tree structure and what's branch structure. What
>> I've been proposing for years now. :)
>>
>
> This sounds like an interesting idea. What precisely is the idea?
>
I'll have to dig it up. But basically it means introducing proper
branches (and tags) as first-class objects to the repository, like every
sane version control system has, instead of relying on flaky
tree-structure conventions that fall on their face as soon as
project/repository structure becomes slightly more complex than the
basic trunk/branches/tags that we use.
It was a nice and interesting and conceptually clean idea a long time
ago, and I supported it for its simplicity, but over the years I've seen
it cause so many problems in real life that I find it really, really,
really hard to justify. The *only* point in favour of
branches-as-directories that I can still make stick is that it's
"simpler to understand for non-techy folks not familiar with version
control." Do tell, how many of those have to manage complex software
projects?
>> P.S.: BTW, this proposal reminds me of the "really simple" idea that was
>> svn externals, it would "work just fine" until we could get real links
>> in the repository and such ...
>>
>
> What's not working with externals, apart from the issues filed against
> files externals?
>
There are a number of worms in that can that I really don't like, though
some have ben alleviated over the years. The first and foremost is that
a working copy constructed from externals behaves differently than one
that is not; and it's every client's responsibility to try and fake
seamless operation. That just feels unnatural and wrong to me; and
introduces churn and bloat and edge cases. Witness the fact that we're
only now, after 9 years, getting support for atomic commits of externals
to the same repository; remember how long it took for relative externals
to happen, so that clients were not bound to a specific schema for
repository access.
Last but not least, people *still* request a feature analogous to CVS's
modules, which ie what externals were originally supposed to provide.
All in all, externals are "almost like real in-repository symbolic
links", just like the svn:branch-root property would be "almost like a
real first-class branch."
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2393034
Received on 2009-09-09 20:17:40 CEST