Re: What would be the best way to create "working repositories"?

Hi Tom,

On Tue, Jun 29, 2010 at 09:37:24AM -0400, Tom Malia wrote:

> I do understand that my people will have to get a little more sophisticated
> about Subversion than "it's just a file share" and I think you understand
> that my statement of the simplicity "requirement" is to say that, I have to
> keep how much deeper they need to go as limited as is practical and still be
> able to implement a solution.
>
> I believe I will be taking your advice about just use real "branches" in the
> "main" repo..
>
> I myself am no Subversion "expert". I don't do a lot of "merge" stuff.
> BTW, I and almost all the developers on this project use TortoiseSVN almost
> exclusively as their SVN interface.
>
> Can you perform "merge" functionality directly "at the repo" or do I need to
> check out working copies to perform these processes?

You always need a working copy. And if you're going to do the merging
(instead of the developers), you might want to have them ready to answer
questions if conflicts arise.

A good strategy for your setup might be:

1. assign developer A a particular feature to implement
2. create a branch for that feature and tell the developer to use this
to check in his/her work in progress (whether or not this is a "private"
branch is solely an organisational decision)
2a. (optional) the developer may merge-in changes to the main branch on
demand
3. if the work is done, do a --reintegrate merge into the trunk (or
the branch of the main product). After that, the feature branch is
considered dead (but may be revived).
4. create a new branch for the next feature (even for same developer),
so he/she will pick up the latest developments

HTH,

Tino.

> -----Original Message-----
> From: Andy Levy [mailto:andy.levy_at_gmail.com]
> Sent: Tuesday, June 29, 2010 9:17 AM
> To: Tom Malia
> Cc: users_at_subversion.apache.org
> Subject: Re: What would be the best way to create "working repositories"?
>
> On Tue, Jun 29, 2010 at 08:54, Tom Malia <tommalia_at_ttdsinc.com> wrote:
> > I’m looking for an easy way to allow programmers on a large project to
> > create something equivalent to a personal “branch” on the main project
> that
> > they can check their “Work In Process” (WIP) in and out of while they
> > actively develop a feature or enhancement over the period of several days
> to
> > several months.  Then when they feel it’s ready they need to do the
> > functionally equivalent to merging the branch back into trunk.
> >
> >
> >
> > It appears that all this would be pretty simple if they literally did just
> > create a branch on the main project.  However, for a number of different
> > reasons, I’d prefer that they could have a separate repository for their
> > WIP.
>
> Developer/feature branches really are the best way to go here,
> especially given your need to keep things simple and abstract the
> actual Subversion usage away from your users as much as possible.
>
> > The scenario I’m thinking of is one in which there’s a main company that
> > controls the project and tightly manages the Subversion Repo for it.  They
> > are granting subcontractors rights to check-out parts of the project from
> > the main repository but they only want to allow those subcontractors to
> > “check in” product that is ready for at least Beta testing.  In the mean
> > time, the subcontractors want to be able to check their WIP files in and
> out
> > of a repository over the course of the days or weeks that they are working
> > on it.
>
> Why not allow those subcontractors to commit to their private
> branches, then have someone central who is the "gatekeeper" and either
> merges from the branch to somewhere else, or accepts patches, at the
> beta stage?
>
> > One thought I had, that I’d like to know if there’s an easy way to do it
> or
> > if I’m just heading down the completely wrong path.
> >
> > I’d like to be able to:
> > 1)       “export” sections of the “main” repository
> > 2)       Then add the directories that were just exported to a repository
> > that would the “working repo”
> > 3)       Check out the stuff just added to the “working repo” to a
> “working
> > copy” (WC)
> > 4)       Developer does their development in this WC, checking things into
> > the “working repo” whenever they wish to make sure the have a snapshot or
> > backup of their work
> > 5)       When the developer feels they are ready to “merge” their work
> back
> > in to the “main” repo they would do something like:
> > a.       Check out the equivalent section of the “main” repo to a separate
> > WC
> > b.       Delete everything from that WC
> > c.       Copy everything from the “WC” that came from their “Working repo”
> > to the now “empty” WC from the main repo
> > d.       Diff the current files in the “main” WC against the current
> version
> > of the “main” repo and resolve conflicts
> > e.       Check the WC from the “main” repo back into main
> > f.         Delete all WC folders from their local machine
> > g.       Delete the entire “working repo”
> >
> > One big flaw I see in this is, I’m not sure how deletes would be tracked,
> > though I’m sure there’s plenty of other problems with this that I haven’t
> > thought of.  But then I’m guessing I’m not the first person to want to do
> > something like this.
>
> The other big flaw is that it prevents changes in the central
> repository from propagating down to your subcontractors. If you keep
> it all in one repository, you can merge changes from trunk (or other
> branches) to each developer's private branch. There's a lot of
> overhead here and a huge margin for error & possibly even loss of
> data. Portions of step 5 would be covered by svn_load_dirs.pl but
> overall I'm having trouble understanding how this solves your
> situation well while satisfying your below requirement.
>
> > A key aspect is, the end result HAS to be REALLY easy to teach people to
> do
> > and I need it in a Windows environment.  Currently most of the developers
> > are not interested in knowing any more about Subversion than what they
> know
> > right now, which is, it acts “kind of like a network share”.
>
> I'm afraid this may break *any* solution proposed. At some point,
> people *do* have to understand the tools their using, especially if
> they're using them in a non-standard way.
>
> SVK or git-svn may be able to meet your technical requirements without
> too much trouble, but they'd probably break your "people"
> requirements.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."
www.tisc.de