[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Reality check

From: Branko Čibej <brane_at_xbc.nu>
Date: 2007-12-15 04:26:39 CET

Karl Fogel wrote:
> Branko Čibej <brane@xbc.nu> writes:
>
>> IMNSHO, we should first support the mainstream CM paradigm, then worry
>> about edge cases such as yours. Having the branch and directory
>> namespaces conflated is sexy for small projects but horror on
>> moderate-sized ones. And on large projects, you end up inventing branch
>> namespace hierarchy where the tool doesn't support it.
>>
>
> I'm all for distinguishing formally between branches and copies, but
> I'm not at all convinced it's problematic to have branches live in the
> directory hierarchy. Kind of the opposite: I've liked it so far!
>
> This may be because I lack some important bit of experience. If so,
> and if you have that experience, Branko, please share...
>

The first problem is repository layout.

Lets take a relatively simple example. We'll have a repository where we
store several code modules and some design documentation (which we don't
want to branch). OK, so the layout will be:

    /
      docs/
      code/
        trunk/
        branches/
        tags

Hmmm, wait ... I want each module to have its own lifecycle, and I want
a place for importing upstream stuff that's separate from other branches
... so ...

    /
      docs/
      code/
        upstream/
        ModuleA/
          trunk/
          branches/
          tags/
        ModuleB/
          ...

(Note that I'm perpetuating the the illogical specialness of trunk, to
make things more confusing). Oh, then I want to make tags for upstream
imports (don't ask me why since they're not much use for merging); and
BTW, ModuleB is actually ProjectB and has its own submodules with
independent life cycles ...

    /
      docs/
      code/
        upstream/
        tags/
        ModuleA/
          trunk/
          branches/
          tags/
        ProjectB/
          ModuleC/
            ...
          ModuleD/
            ...

And so on. Soon you find that you need map and a full-time seer to find
your way through the mess. And one day you find that bits of ModuleA
have to be visible from ModuleD on a predictable relative path, which is
quite impossible because of all the intervening branch names, and you
can't use externals for that; absolute externals won't work for people
accessing the repository from remote (because of different names, for
example); relative externals won't because of all the intervening branch
names, and oh yes, every time you create a tag you'd /still/ have to
change all externals ...

So you give in, decide to take a huge risk to your multi-million-LOC
project and restructure the repository. This time you keep it as simple
as possible. All top-level directories are branches (br) or tags (tg),
everything uses the same branch structure, you always branch the whole
repository (it's cheap, right) and relative paths stay stable.

    /
      br.main/
        docs/
        code/
          ModuleA/
          ProjectB/
            ModuleC/
            ModuleD/
      br.upstream/
        code/
          ...
      tg.0.10.4/

Nice. And looks suspiciously as if the top level of the repository is a
separate namespace. Add a task branch that is a subbranch of 'br.main',
let's call it br.main.task1 for the sake of argument ... pity I can't
call it main/task1, that would be even more obvious ... and an even
bigger giveaway.

The example above is anything but farfetched (I've seen all the steps --
except the last one :) -- repeated over and over).

I can hear the counter-arguments:

    * "You can start with a simple structure and move things around later."
      With the available merge and history tracking? Hollow laugh.
    * "The last solution is not much different from the suggested
      trunk/branches/tags."
      Indeed it's not. Makes you think, why all that flexibility if you
      end up with top-level branches and tags, or you end up going insane?
    * "But, but ... our current way is more /flexible/!"
      Right. In many cases flexibility is a curse. This is one such
      case. Ask any ClearCase user what happens if you try to exploit
      all of CC's flexibility.

Everybody keeps inventing myriads of similar-but-different solutions to
the branch-structure problem, the same mistakes are repeated time after
time exactly because of some flexibility that no-one really needs.

We managed to expose a sexy implementation detail as a first-class UI
paradigm. Imagine having a C compiler that requires you to manually
annotate invariants for the loop optimizer, or worse yet, wants you to
mark bits of code that can be candidates for branch-delay slot
scheduling. Feel the horror?

Let's stop congratulating ourselves and admit that branching and tagging
in Subversion are so flexible they hurt. Users want to say, "make a
branch" or "I'm working on that branch now" or "tag this for posterity."
Yes, these are basically user-interface things and "you can create
aliases and use shell variables" but that's again the user (not even
client) doing the server's job.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 15 04:27:08 2007

This is an archived mail posted to the Subversion Dev mailing list.