On Fri, Jun 19, 2009 at 8:04 AM, Michael Miller
<mmiller_at_unitrindirect.com>wrote:
> I'm looking for feedback from anyone who might have worked with or can
> provide the pros & cons of multiple developers using a shared working copy.
>
> This process was proposed to solve some issues with a development group
> that maintains a vendor package (mostly COBOL) with many generated items and
> a unique build process.
>
> I've provided some reasons why this is may not work, but being relatively
> new to Subversion I would like some feedback from more experiences users.
im not sure how you intend to use the shared wc in your case, however, i
have discovered a couple scenarios where it proves very useful. often
times, merge conflicts will be so bad, that i cant solve them on my own,
after all, its code i havent written and know little about..
so, what i do in some cases, is 'publish' a working copy on a common server,
that all the requisite devs (committers) have accounts on. i then run the
merge, and mail the devs. they know which files theyve worked on, and
quickly hop in and resolve the conflicts. any remaining ones, i can make a
determination on. but you can see how this is beneficial..
. the process is asynchronous, developers dont need to stop what theyre
doing to come look at a merge conflict, totally out of context
. i dont have to chase through the log, trying to figure out who to ask to
come look at a conflict(s) which means i save time too
. other people arent relying on me to edit the code theyve been working on.
they are the content experts on their code changes, so its likely the
conflict resolutions will be better than had i done them all myself
there was another great application of a common working copy at my last
job. we had the typcial, dev / qa / prod, tiers code would flow through.
the approach was to have a trunk (stable production code) working copy on
the 'qa' domain webroot. we would then svn merge into the working copy from
a dev branch once work was ready to be tested (merging subsets of the branch
corresponding to the new feature/bugfix). if the test failed, the files
were reverted (no harm done). if the tests pased the files were committed,
and then ready for production. this doesnt neccessarily require that there
be one such trunk wc, all developers could have had their own, however, it
simplified things w/ the common wc, being that we had like 3 developers or
so who ever worked simultaneously on the project.
-nathan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2363672
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-19 22:40:27 CEST