Thanks Andy. This is an extremely useful reply. 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? Tom Malia T&T Data Solutions L.L.C. -----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.
