On Feb 22, 2009, at 10:40, void pointer wrote:
> Here is a quote from my co-worker in response to me asking "Why do
> you feel externals are so bad?":
>
>> Because relative externals are only relative to the repository.
>> They still need to be hand modified in order to branch or tag
>> properly.
Note that the svncopy.pl script exists to assist you when branching
and tagging, doing these modifications automatically for you, even
adding the revision for you to peg it to the revision that was in use
on trunk when you branched or tagged. But it's a better idea to pin
your externals to a particular revision at all times, even in trunk.
>> With externals your commit can fail after an external has been
>> committed or vice versa. This can and has in the past (at method)
>> resulted in partial check-ins.
I'm not sure what this means, because partial-checkins should not be
possible with Subversion; it is one of the CVS deficiencies
specifically addressed by Subversion. Now, it is true that you must
commit and changes to your external separately from the code that
uses the external. I don't consider this a deficiency though; I see
these as two steps that should be done separately anyway: 1) change
the external library to have the new feature or bugfix you want; 2)
change the software that uses the external library to bring in this
change by updating the revision of the external definition and making
any corresponding necessary changes to the software.
>> Externals also caused revision numbers in the repository to be
>> additionally incremented on each check in once for each external.
>> This makes it harder to track down and/or revert changes. I'm not
>> sure if relative externals solve these problems or not.
Relative externals don't change this. It's not a problem that the
repository revision number is increased; it is, after all, only a
counter of the number of changes that have been made to the
repository. And as I said above, I see changing the external library
and changing the software using the library as two discrete steps
anyway.
>> Externals make working with subversion harder. Externals make it
>> noticeably slower. It takes me 35 seconds to do an update when I
>> am up to date.
Subversion handles the external as a completely separate and
disconnected working copy, so yes, there is some additional time
needed to update that second working copy. Different repository
access methods take different amounts of time, so certainly https
connections will take more time to set up than svn or file
connections. If you have multiple externals in your project, it can
add up. But to give an example, a project I have at Google Code,
"Canviz", has three externals to its own repository, and running "svn
up" takes 6 seconds including all externals, over https. Granted, it
is a small project, but I wanted to point out that adding externals
does not have to immediately mean slowing things down a lot.
http://canviz.org/
>> Viewing the history of the checkout is also more difficult as
>> revisions to the externals do not show up when showing the log of
>> your working copy root folder.
This shouldn't impede your ability to see changes in the log. The log
for the external library will of course show the changes made to the
library. And the log for the software using the library should show
every time the external is updated to pull in new changes from the
external library, hopefully noting which specific new feature of the
library is being sought by this particular update.
>> I'd go as far as to say having externals in the primary part of
>> the repository should be a subversion anti-pattern.
I can't agree with that. IMHO sometimes it is the correct solution to
a problem. Of course, if it doesn't work for you, don't use it.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1211511
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-23 00:29:30 CET