Karl Fogel wrote:
> Branko Čibej <firstname.lastname@example.org> 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:
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 ...
(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 ...
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.
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
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
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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Dec 15 04:27:08 2007