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

Re: Re: [Issue 533] New - implement reserved checkouts

From: Jeff Putsch <putsch_at_mxim.com>
Date: 2002-08-02 20:03:05 CEST

On Fri, Aug 02, 2002 at 10:46:13AM -0700, Bill Tutt wrote:
> If it's not pointless then they can branch it. :)
>
> Bill
> ----
> > From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> >
> > "Bill Tutt" <rassilon@lyra.org> writes:
> > > Well, if you can't diff/merge the sucker than having two people make
> > > changes at the same time is pretty pointless.
> >
> > If they're both aware that they're doing it, but they keep doing it
> > anyway, then it's probably not pointless. They could be each making
> > alternate versions of the file, to be chosen between later, for
> > example.

There are some reasonable uses for systems like Subversion where having
people be able to make changes at the same time to a given binary file
not desired. If they really want/need to do this (e.g. alternate versions)
then a branch or a copy is required.

In my particular case we are evaluating Subversion for use as a revision
system for CAE software (Cadence in particular) when used in a distributed
design environment -- multiple sites across the world. In this case having
the locks/reservations on binary files would be very useful. We really do
not want two users to be making changes to the same schematic or layout
at the same time. Yes we can handle the collision later, but preventing
it with locks is much more desirable.

Jeff.

-- 
Jeff Putsch                       Email: putsch@mxim.com
Maxim Integrated Products        Office: (503)547-2037
High Frequency CAD Engineering
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 2 20:04:12 2002

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

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