[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Design Questions

From: John P Cavanaugh <cavanaug_at_soco.agilent.com>
Date: 2000-07-28 07:47:13 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.