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

Re: Atomic updates

From: Scott Palmer <scott.palmer_at_2connected.org>
Date: 2005-11-23 20:24:23 CET

On 23-Nov-05, at 1:43 PM, Erik Huelsmann wrote:

> On 11/23/05, Scott Palmer <scott.palmer@2connected.org> wrote:
>> On 23-Nov-05, at 5:22 AM, Erik Huelsmann wrote:
>>>> Does it have any other advantage than guaranteeing that you will
>>>> not
>>>> get a mix of files from different svn revnums because HEAD changed
>>>> while you performed the update in several steps?
>>> NO NO NO!!!!!
>>> Please don't suggest that's possible with Subversion! That's a
>>> problem
>>> with CVS which we have solved!
>> NO NO NO you haven't... if you use svn:externals to include shared
>> code into your project working copy like many of us do.
> Yes, we have. Externals (as the name suggests) are not meant for
> maintaining intra repository references. Yes, I know lots of you use
> them for it, but it's not part of their design goal and - not
> surprisingly - they don't completely fit the purpose.

Fair enough. But the need for intra-repository references comes up
quite often and svn:externals is promoted as the only applicable
solution that subversion has to offer. (Where a straight copy
doesn't to the job.) Leaving those of us that need the feature
without a solution to the original CVS problem that is supposed to be

It only bring it up because it is one of those issues related to
doing things atomically that affects me daily. That and the
inability to check IN multiple workspaces as a single atomic
operation; which apparently worked at one time, but was broken to
fix some other issue, as I understand it.

Heading off-topic now, so feel free to start a new topic if you would
like to discuss it further.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 23 20:26:27 2005

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.