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

RE: taking temperature on externals

From: Bert Huijben <rhuijben_at_sharpsvn.net>
Date: Sat, 4 Apr 2009 23:40:26 +0200

> -----Original Message-----
> From: Mark Phippard [mailto:markphip_at_gmail.com]
> Sent: Saturday, April 04, 2009 5:16 PM
> To: Neels Janosch Hofmeyr
> Cc: dev_at_subversion.tigris.org
> Subject: Re: taking temperature on externals
>
> On Fri, Apr 3, 2009 at 9:06 PM, Neels Janosch Hofmeyr <neels_at_elego.de>
> wrote:
>
> > for an article on Subversion 1.6 we're writing, I'd like to know what
> the
> > intentions are with the externals feature.
> >
> > I notice that there is a difference in behaviour: the new file
> externals are
> > included in a recursive commit, while directory externals simply
> aren't.
> >
> > What are the intentions? Some users out there seem very eager to have
> some
> > way of allowing recursive commits of external directories. Is that
> probable
> > to ever happen?
> >
> > (( Testing around, I found that it makes no practical sense to commit
> an
> > external when it has an explicit revision number. So, I for myself am
> > thinking it'd be good to a) handle both directory and file externals
> the
> > same way, by b) excluding them from commit recursion if and only if
> they
> > have a fixed revision number. Meaning that revision-less dir-
> externals would
> > be included in recursive commits, while "revision-ful" file-externals
> > wouldn't. It seems to cater for all the needs: If I want a patchy
> working
> > copy to commit in, I don't supply revision numbers and am working on
> HEAD.
> > Makes sense. If I want to have a fixated snapshot of something, I
> provide a
> > revision number and can't commit on it. Makes sense!
> > I'd even go as far as warning about any modifications made on
> externals with
> > a fixed revision number... ))
> >
> > Thanks for any hints and pressure readings.
>
> FWIW, at the API level you can already do this. I think we only
> prevent it in the command line. In Subclipse we do all commits to
> externals from the same repository in a single transaction (always
> have) and it works fine. I *think* TortoiseSVN might provide this as
> an option.

Recursive commits don't work over externals and the CLI defaults to a recursive commit. (A recursive commit tries to get a recursive lock over the commit base and then assumes the externals are locked.. which gives an error. Non recursive commits lock only the directories changed by the commit which may or may not work for externals).

Only non-recursive commits work over a working copy and externals below it, but these commits can't contain directory deletions. (As these deletions require a recursive commit).

And when I tried to get this algorithm implemented for AnkhSVN (In the 1.5 timeframe) I broke a few working copies... So I wouldn't call atomic commits over externals supported. :(

See also:
http://svn.haxx.se/dev/archive-2008-07/0247.shtml (original investigation with several replies)
And a delayed followup:
http://svn.haxx.se/dev/archive-2009-01/0733.shtml (Breakage report on missing checks in these scenarios)

WC-NG should make it much easier to fix these scenarios as a working copy and all its externals will all be handled in the same database.

        Bert

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1546185
Received on 2009-04-04 23:40:49 CEST

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.