From: Michael Marcin (mmarcin_at_[hidden])
Date: 2007-08-03 13:30:50
David Abrahams wrote:
> on Wed Aug 01 2007, Douglas Gregor <doug.gregor-AT-gmail.com> wrote:
>> On Aug 1, 2007, at 3:51 AM, Henrik Sundberg wrote:
>>> 2007/8/1, Douglas Gregor <doug.gregor_at_[hidden]>:
>>>> The main Boost development branch is available via anonymous, read-
>>>> only checkout at:
>>>> Or for developer read/write access at:
>>> Will this setup work with externals?
> How? IIUC, the externals will need to refer to the https:// address
> for developers and the http:// address for everyone else... unless the
> https:// address is really available for read-only anonymous access
> also. In that case maybe we ought to encourage people to use the
> https:// address universally and just maintain the http:// one as a
> fallback for people with crazy firewalls, to ease the transition from
> user to developer.
>>> Are externals forbidden?
I'd just like to mention again that I've had lots of subtle issues with
externals and I think they should be discouraged or forbidden.
Not the least of which is that if you are planning to move to a system
that involves lots of merges, branching, and tagging all the externals
must be branched and updated individually or they will point to the same
Updating a working copy has a noticeable performance hit when it reaches
It might be a TortoiseSVN bug but if I have an external named B in
folder A and I remove the external link and create a folder named B
inside of A the external link has to be removed and committed on each of
our developers machines or they have to do a clean checkout before they
can successfully update again.
If the repository URL ever changes then all internal externals must be
updated by hand. This means that revisions must be made on tags which is
never good practice.
True externals (links to other repositories) can go away in the blink of
an eye as you have no direct control over them and can thus cause your
checkouts/updates to fail.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk