While reading the design doc I had a few questions, maybe
someone could help clarify things for me.
#1 - Atomicity on merges
I understand the atomicity on commits and how the whole
set of changes is rolled into a new repository version.
This is cool, I like it. But what happens if I want to
merge from one branch to another, but Im not at a location
in the directory tree such that I would "get" all the
files that were changed.
ie. something like project foo on the main trunk
pwd=/project/foo
modify files ./dir1/junk
modify files ./dir2/foo
modify files ./dir2/bar
svn commit (which creates a new repository version with
all 3 file modifications)
Now what happens if Im on branch2 for the same project
pwd=/project/foo_branch2/dir2
svn update -j trunk
Do I only get the merge for files foo & bar??
What about junk??
What I am getting at here is if you try work under a model
where every commit is for a specific reason (ie. a feature
or bugfix) then in theory the whole change is a logical
set that shouldnt be divorced from each other.
#2 - Granularity of ACL's
I understand that their are properties that can control
access for files and directories. But what about
branches, or tags???
One of the first things I had to fix with CVS and triggers
was the ability to lock certain branches and perhaps only
open them up to certain developers during our QA process.
(Note: Im not suggesting that triggers is the way to
address this in subversion, in fact I hope its *not*
the way to do it)
Ideally I would hope for something that allowed me to
control the same properties for branches/tags as I would
for files.
#3 - Triggers
I found no mention of triggers in the design document. This
was a bit concerning to me in that adding them on later
is fraught with problems, especially in terms of what
to do if certain pre-triggers fail during a commit
process.
One of the nicest things about ClearCase is its *extensive*
support for hooking in pre & post triggers to just about
any operation.
Besides just identifying all the possible places where
triggers could be allowed we also need to determine *where*
they run. Do they run in context of the client or the
server?? There are prons & cons for each, Ill spare you
my analysis on this as Im sure everyone can quickly
come up with their own list. Ill also try to avoid
a scripting language war also...
-----------------------------------------------------------------------
John Cavanaugh Agilent Technologies
R&D Program Manager 1400 Fountaingrove Pkwy
CAD Data Store Santa Rosa, CA 95403-1799
Email: cavanaug@soco.agilent.com Phone: 707-577-4780
707-577-3948 (Fax)
-----------------------------------------------------------------------
When schemes are laid in advance, it is surprising
how often the circumstances fit in with them.
-- William Osler
-----------------------------------------------------------------------
Received on Sat Oct 21 14:36:06 2006