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.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2363524
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-19 16:16:17 CEST