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