On Jul 2, 2009, at 2:29 PM, Robert Dailey wrote:
> Hey everyone,
>
> I've been using Subversion for a really long time and I've always
> wondered what the best structure would be for tagging. Ever since
> sparse checkouts came around in 1.5, a couple of more options have
> become available. Granted, being able to fully recommend a specific
> structure has a lot to do with the requirements one has on version
> control, but hopefully there is a pattern that is more commonly
> accepted than the others. So far here are a couple of scenarios I
> see. We'll assume a very simple use case:
>
> We have a project (Project1) that is fully contained in a single
> directory (It may also have sub directories to further categorize
> the different parts of that project. Secondly, we must be able to
> easily tag this project at various intervals in the development
> cycle. Project1 also has 2 dependencies: Library1 and Library2. In
> order for Project1 to be compiled, linked, or otherwise represent a
> complete product, it must know where Library1 and Library2 are so it
> may have access to its source. Furthermore, Library1 and Library2
> are also used by several other projects in the repository not
> mentioned here. One of our requirements is that we do not duplicate
> Library1 or Library2 in the repository itself in any way.
>
> Before I go any further, I want to discuss what requirements I have
> on tagging. Technically, a tag is nothing more than a copy or a
> branch. However, conceptually, a tag should be much more. A tag may
> not necessarily be a copy of a single branch, but perhaps multiple
> branches. A tag must capture the full dependency tree of a project
> in order to become a true tag. While (technically) tags in
> Subversion behave at a very low-level and primitive way, we can
> structure our repository in such a way that makes tagging a bit less
> painful. Additionally, we can also create scripts that assist in
> creating tags (More on this below).
>
> Having described what is expected of a tag (conceptually) and what
> our particular use case is, I can think of a couple of options
> (listed below). Note that some of these may be inferior to other
> solutions. My goal is simply to prove all of the possible ways to
> solve the problem. The point of this discussion is to figure out
> which of those solutions is the most reasonable given a certain set
> of requirements.
> As we discussed earlier, Project1 has two dependencies: Library1 and
> Library2. One way to make sure Library1 and Library2 are available
> to Project1 (without duplicating them in the repository) is to use
> externals (Relative externals). We can create an svn:externals
> property and apply it to Project1's root directory, so when we do a
> checkout we pull down both Library1 and Library2.
A minor problem with SVN externals in this case is that the knowledge
of what library versions were used in the build may not be evident in
the source. If you export the project you may not be able to tell
which versions of the libraries were included. That may not be an
issue as long as SVN is readily accessible, or the version or tag info
is included in the source.
svn:externals used in a checkout always checks out the externals as
well, even though you may not want to do that. The developers have to
be really careful, especially if the external points to a tag. They
could change a file in the library without realizing it and screw up
the tag when they commit. I wish there was a way to indicate in
svn:externals property that all files should be checked out read-only,
or just exported.
If the libraries are pretty large and the developer is working on
other projects that share them, a different approach may be more
efficient, perhaps exporting copies of the libraries separately into a
shared location. This is especially true when you start talking about
getting build tool chains. A project may require you to use a
particular version of a compiler to build it, but svn:externals is not
the best way to get it.
> Sparse Checkouts. We can keep all projects and dependencies in the
> repository in one "flat" structure. In other words, at the root of
> the repository we would have Project1, Library1, Library2, and any
> other projects or other libraries. When we do a checkout and we only
> want Project1 and its dependencies, we rely on checkout depth to
> choose only the parts of the repository we want. This would not have
> been possible in pre-1.5 builds of subversion.
I've not used sparse checkouts, but the developer would have to know
the dependencies and manually checkout the components. You would
definitely need to have instructions in the project so the developer
knows which components to get in the sparse checkout. If the project
only need one or two libraries, this may be OK, but any more than that
it becomes burdensome for the developer.
> Scripts. We can check out Project1 and each of its dependencies
> independently. We could use a script for this, which would make sure
> that each subsequent checkout is placed in a correct relative
> location. This requires each project to reach outside of its own
> workspace (Outside of the root of that working copy) in order to
> step into other working copies for the files it needs.
We have several projects that use a script to get external components
and it has worked quite well. The advantage for a release manager is
that they can quickly assess what versions of various components go
into a release (in our case, there could be more than 20). Editing a
file with with a list of components and versions is generally easier
for developers than editing a property list, and seems more natural.
The main advantage of using a script is you have much more control and
flexibility. For example, you may have some of your components stored
on networked drive, SharePoint, CVS, etc. The only way to get them is
to use a script.
A minor disadvantage is that the developer must manually run the
script to get the components. If the script is run as part of the
build process, that gets around the problem.
-- John
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367846
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-03 18:55:57 CEST