[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Shared working copy

From: Anderson, Aaron <AndersonA_at_gsicommerce.com>
Date: Fri, 19 Jun 2009 10:27:59 -0400

Sometimes people get around these issues by forgoing individual
committals and running a nightly cron job to commit in the changes for
that day. Its not elegant and you loose visibility of who made which
changes, but you will at least have traceability of when changes
occurred.

- Aaron Anderson

-----Original Message-----
From: Andy Levy [mailto:andy.levy_at_gmail.com]
Sent: Friday, June 19, 2009 10:15 AM
To: Michael Miller
Cc: users_at_subversion.tigris.org
Subject: Re: Shared working copy

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&dsMessageI
d=2363524

To unsubscribe from this discussion, e-mail:
[users-unsubscribe_at_subversion.tigris.org].

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2363527

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-19 16:29:16 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.