On 09/09/2009 02:17 PM, Branko Cibej wrote:
> 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
It's really a leaky abstraction of sorts. Light weight branches and tags
by treating everything as a tree, allowing for shallow copies. Super
cool. Allowing these to be visible as regular directories, making it
super easy for newbies to understand, and providing great flexibility
for complex branching structures. Awesome!
But wait - we have to support merging? And merge tracking? Who uses
those? :-) Oh - everybody. Hmm... Well, let's go back in and try to
That's how I see history in this regard. :-)
I think some of the cool ideas can be retained while putting some
practical re-architecture into place. I would even suggest locking out
the really complex stuff - like allowing people to change multiple
branches in the same commit, or moving branches into other branches.
This sort of re-architecture causes trouble and makes merging impossible
or near impossible. If they really need to do such things - the merge
info is garbage anyways, and it may as well be implemented as a full
delete + create for each of the files - not a tree copy or a merge.
Received on 2009-09-09 21:17:42 CEST