You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by John P Cavanaugh <ca...@soco.agilent.com> on 2000/07/28 05:47:13 UTC
Design Questions
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
-----------------------------------------------------------------------
Re: Design Questions
Posted by "Jonathan S. Shapiro" <sh...@eros-os.org>.
> > If I understand you correctly, this is one of those cases that I'm
willing
> > not to support. People certainly won't always do the right thing, but
> > supporting a method to specifically *prevent* them from doing the right
> > thing seems like a bad idea.
>
> I definitely can understand not wanting to support this as it was a very
> unusual case. But I think defining right/wrong is inappropriate as it
> is situation dependent. Ill skip going into all the IP issues that were
> involved with this particular situation.
I take your point about right/wrong. I'm still not convinced that I want to
support this scenario, but I will certainly give it more careful thought.
shap
Re: Design Questions
Posted by John P Cavanaugh <ca...@soco.agilent.com>.
On Fri, Jul 28, 2000 at 07:06:01PM -0400, Jonathan S. Shapiro wrote:
> > At a previous job we had contracted out all of our "learning products"
> > and "localization". Due to a legacy architecture these files were
> > spread all over the tree. We didnt want the contractors to have
> > access to all the source code, but we did want them to use the
> > version control system so their updates would appear in our daily
> > builds...
>
> Let me make sure that I understand this correctly. You wished to ensure that
> it was completely impossible in principle for these contributors to even
> *attempt* to compile their changes before checking them in and screwing up
> the tree?
Believe it or not that was the case. They didnt have access to the other
files, but they did have access to the resource files (it was a win32
environment) they were chaning and that allowed them to check window sizing
etc.
> If I understand you correctly, this is one of those cases that I'm willing
> not to support. People certainly won't always do the right thing, but
> supporting a method to specifically *prevent* them from doing the right
> thing seems like a bad idea.
I definitely can understand not wanting to support this as it was a very
unusual case. But I think defining right/wrong is inappropriate as it
is situation dependent. Ill skip going into all the IP issues that were
involved with this particular situation.
-----------------------------------------------------------------------
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)
-----------------------------------------------------------------------
The main thing people really regret
are the risks they didn't take......
-- Unknown
-----------------------------------------------------------------------
Re: Design Questions
Posted by "Jonathan S. Shapiro" <sh...@eros-os.org>.
> At a previous job we had contracted out all of our "learning products"
> and "localization". Due to a legacy architecture these files were
> spread all over the tree. We didnt want the contractors to have
> access to all the source code, but we did want them to use the
> version control system so their updates would appear in our daily
> builds...
Let me make sure that I understand this correctly. You wished to ensure that
it was completely impossible in principle for these contributors to even
*attempt* to compile their changes before checking them in and screwing up
the tree?
If I understand you correctly, this is one of those cases that I'm willing
not to support. People certainly won't always do the right thing, but
supporting a method to specifically *prevent* them from doing the right
thing seems like a bad idea.
If there is some other, conceptually sound reason, I'ld have no problem.
If by "we didn't want them to have access" you mean "we didn't want them to
have WRITE access", then the solution in DCMS would be to grant them
read-only access to the development branch. With read-only access, they can
create a writable branch of their own and then one of your team can
integrate their changes. This doesn't prevent them from modifying any file
they want, but it does allow you to check what was changed.
shap
Re: Design Questions
Posted by John P Cavanaugh <ca...@soco.agilent.com>.
On Fri, Jul 28, 2000 at 08:42:54AM -0400, Jonathan S. Shapiro wrote:
> [I know this isn't the DCMS list, but the descriptions of rationale may be
> of use hear.]
>
> > #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???
>
> Again speaking for DCMS, we're actually taking the view that there
> *shouldn't* be access control on files or directories. We do it only on
> branch and project (we may extend this to branch versions, but that creates
> merge problems). If you have access to the branch you should have access to
> the contents referenced by that branch.
Hmm. I guess you could achieve equivalent results using that method but
it seems a little less intuitive to me.
While I know commercial development practices arent really relevent for
open source folks Ill give you an example where having both control of
branches and files/dirs is of benefit.
At a previous job we had contracted out all of our "learning products"
and "localization". Due to a legacy architecture these files were
spread all over the tree. We didnt want the contractors to have
access to all the source code, but we did want them to use the
version control system so their updates would appear in our daily
builds. In this situation having the ability to create a different
class of users that can read all the directories in the tree, but
only have read/write access to the files they needed is quite
valuable. Note this couldnt have been accomplished (at least not
easily) using different branches for different folks.
In general my philosophy on tools is to provide as many orthogonal
features and extensions as possible, then let the user decide best
how to utilize them. I guess its sort of making a fancy swiss army
knife with lots of options and letting the user determine which
subtool/feature is appropriate for thier specific/custom task.
-----------------------------------------------------------------------
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)
-----------------------------------------------------------------------
They can because they think they can.
-- Virgil
-----------------------------------------------------------------------
Re: Design Questions
Posted by "Jonathan S. Shapiro" <sh...@eros-os.org>.
[I know this isn't the DCMS list, but the descriptions of rationale may be
of use hear.]
> 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.
Speaking for DCMS (another current CM effort), this is a policy issue. Prior
to the point where you are in the production maintenance cycle, you want to
be able to merge subsets. After that, you may wish to impose an all or
nothing policy.
The DCMS "solution" to this is to use scripting code that can embed such
policies. While the specific policies are ad hoc at the moment, our general
view is that the CM system should support well-defined triggers and a
built-in scripting language (i.e. not shell scripts -- multiplatform and
security issues here), and should NOT have random option flags in a config
flie somewhere. The former is potentially maintainable. The latter is less
so, and it has been my experience that in practice option flags are stored
in a single global file which makes them hard to set on a per-project basis
(e.g. .cvsrc in $HOME).
> #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???
Again speaking for DCMS, we're actually taking the view that there
*shouldn't* be access control on files or directories. We do it only on
branch and project (we may extend this to branch versions, but that creates
merge problems). If you have access to the branch you should have access to
the contents referenced by that branch.
The only access control that DCMS has on files/directories devolves from the
use of a cryptographic hash naming scheme for objects. If you know the
object name (e.g. by obtaining it from a configuration record in a branch)
you can get the object, but it is pragmatically impossible to guess the
object names. The net effect of this is that you can have private branches
and versions.
Note that files and directory objects in DCMS are immutable, so there is no
need to write protect them.
Some may object that fred could tell mary the name and then mary would have
access. In this case fred could also simply ship mary the object, so
protecting the name is not helpful.
shap
Re: Design Questions
Posted by John P Cavanaugh <ca...@soco.agilent.com>.
On Fri, Jul 28, 2000 at 10:44:14AM -0500, Karl Fogel wrote:
> John P Cavanaugh <ca...@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
-----------------------------------------------------------------------
Re: Design Questions
Posted by Karl Fogel <kf...@galois.collab.net>.
John P Cavanaugh <ca...@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? :-)