On Fri, Jul 28, 2000 at 10:44:14AM -0500, Karl Fogel wrote:
> 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
> >
> > 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.
I like the idea of supporting both if possible via a command line
option to update. But I agree we shouldnt deviate far from the cvs
standard.
Another tangentially related question is there anyway to symbolically
name a commit. From the subversion design doc it appears that you
could merge just the change from x.4 to x.5 in the repository to
another branch, which effectively clones changes in an atomic commit
to another branch. This is a *very* powerful feature and basically
is the file based version concept of a change set. I would be
interested in a feature that lets me name my atomic commit so that
later I might be able to query all the symbolic names on a branch.
This would allow for things like bugfixes to have a symbolic name
like bugfix_471 and to easily migrate bugfixes to other branches.
sat in release review meetings where we are going over a handful
of changes and assessing benefit/risk etc. The ability to very
easily migrate a change in (because of benefit) or to easily pull
a change out (because of problems) is awesome, especially if you
can do it by symbolic name rather than version number.
> 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.
Its amazing what you can get used to though.... ;-)
> > #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.
Good. So I assume I can lock a branch to only certain users just
like I could prevent access to a file using properties. Im assumming
this is also a constant time operation???
Im skipping ahead here, but I assume there will be pre/post triggers
for branch creation??
> > #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? :-)
Well one situation I can think of is how to deal with errors in
pre-command triggers and/or design decisions affecting policy
decisions.
Here is one I though of that makes it difficult to implement policy
because of a design decision. Lets say I want to enforce a branch
naming policy of "all lowercase" and a tag naming policy of "all
uppercase", how would I do that in subversion considering that
a tag is merely a non-instantiated branch.
Thats more of what I meant by fraught with problems. Its just
all the weird policy things that people could think of that
make tacking triggers on later a little difficult.
If feasible I would recommend that we make things as orthogonal
as possible instead of overloading the meaning of things
and determining there true identity later depending on context.
Just a quick question, does anyone else have significant ClearCase
experience??? If not I could probably provide a list of all
the operations that Clearcase allows pre & post triggers on as
a way to share some implementation ideas with the team. Thoughts??
-----------------------------------------------------------------------
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)
-----------------------------------------------------------------------
A good workman is known by his tools.
-- Proverb
-----------------------------------------------------------------------
Received on Sat Oct 21 14:36:06 2006