John P Cavanaugh <cavanaug@soco.agilent.com> writes:
> 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.
That makes sense; but if someone _asks_ for only part of the change,
that's what they get. Subversion can include an informational message
explaining that there are other changes in this commit that are not
being included in the update. It shouldn't update parts of the tree
that the user did not ask to be updated, however.
One might ask whether depending on the user's location in the tree to
determine what they're operating on is a good interface. I think it's
worked pretty well with CVS, though (the situation you describe acove
can, and does, happen with CVS all the time), and it's what people are
used to.
> #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.
Branches and tags are just regular directories (copies), so the same
ACL rules apply.
> #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...
Oh my gosh, there are certainly triggers. I don't know whether we
explain clearly in that doc where they hook in, but they are
definitely there. See documentation about the `plugin' systems (which
also takes care of the scripting language war).
I'm curious why you say adding them later is fraught with problems.
You just add them. What's the problem? :-)
Received on Sat Oct 21 14:36:06 2006