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.l...@gmail.com] > Sent: Tuesday, June 29, 2010 9:17 AM > To: Tom Malia > Cc: users@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 <tomma...@ttdsinc.com> wrote: > > Im 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 its 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, Id 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 Im thinking of is one in which theres 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 Id like to know if theres an easy way to do it > or > > if Im just heading down the completely wrong path. > > > > Id 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, Im not sure how deletes would be tracked, > > though Im sure theres plenty of other problems with this that I havent > > thought of. But then Im guessing Im 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
