I realize that some of us use externals more/differently than was
originally intended, but they work well except for a few small issues,
mainly revolving around the difficulty in pegging externals when
tagging. In my company, we've taken the above to an extreme, where we
actually have two major uses of externals:
1. As described above, we have a very large library of common code
that includes components for various targets including PC, Embedded,
DSP, HDL for FPGAs, etc.
2. Parallel to this common tree, we also have our repository organized
as a set of components, or widgets. A product in our eyes is just a
collection of widgets, so each widget is a node on the tree. Widgets
may be embedded software, pc software, pcb and pcba files, etc.
3. Parallel to these two, we have Products, which are nothing but
folders with svn:externals properties. Checking out one of these
folders will grab, via externals, all of the widgets in that project.
These are used specifically for "tagging" a version of a product, and
generally point to a specific tag of each widget.
As originally discussed, a great solution would be a dialog to view
externals in the current working project. This dialog could then
include the option to update all externals definitions to the current
working copy revision, the HEAD, or a specific revision.
Personally, while this would be nice (and help immensely with use case
#3 above), it seems like overkill to just add the functionality that I
think some of us want: a simple checkbox on the SVN Copy dialog that
allows one to peg all externals when tagging. It may take a couple of
boxes, effectively
__ Peg Externals, with drop-down with the following options:
--Peg Externals to Working Copy revision
--Peg Externals to HEAD Revision
--Peg Externals to Specific Revision
__ Update all Pegged Externals to the selected revision
Arguments against this sort of thing:
"Put them all in one folder and external the folder."
--Including my entire common folder in each external would mean
getting a lot of extra stuff each update (50-60 different modules, of
different types, languages, and targets), and significantly increase
checkout/update time.
"You should be referencing tags of those libraries, not the trunk"
--While this is a noble concept, when creating a new project or
working through a large list of issues, many libraries get new
functionality and it's very helpful to not need to manually modify the
tags each time one wants to change the library.
"You should always peg your externals, and update them before you tag"
--Problematic, because it means someone has to always remember to
update them, and people are forgetful or lazy. What's worse is no one
notices until someone checks out that tag, it builds successfully, but
functionality has changed. This is really bad if you have customer
requirements to maintain past builds. It could be fixed by process,
but it seems more straightforward to let the tools help.
There are others, but they all basically say "your workflow is wrong,
use the 'right' workflow and all your problems will go away."
Thoughts?
Justin
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2384903
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-18 21:10:35 CEST