On Fri, Jun 19, 2009 at 10:14, Andy Levy<andy.levy_at_gmail.com> wrote:
> On Fri, Jun 19, 2009 at 10:04, 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.
> Major con: How do you keep the work of 2 developers segregated? If I
> change file A, and you change file B, then I perform a commit, it
> looks (in the logs) like *I* changed B, and you may not have completed
> your changes to B, and thus what's in the repository is broken
> (compiler errors, maybe).
> Or, maybe we're both working on B at the same time, and we clobber
> each others' changes completely. Now what?
> It's a bad idea from a potential dataloss perspective (note: it
> wouldn't be Subversion causing dataloss here, it'd be the editors &
> workflow), and even worse from an auditing perspective - you have no
> idea who truly made each change.
> Pro: Less disk space used. But disk is cheap.
Another con: If it's on a shared network path, and I upgrade my client
but you don't upgrade yours, you can no longer use your client against
that working copy, because newer clients upgrade the WC format.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-19 16:16:17 CEST