Thanks to all who may still be working on a response to my extensive
newbie questions -- keep 'em coming!. I particularly wan't to thank
William Nagel and Michael Chang (of my SVN/Trac hoster wush.net --
excellent by the way!). Their excellent responses follow my
"nutshell"...
Thanks again!
P.S. How I missed the Vendor branch chapter originally I don't know.
The solutions to my problems in a nutshell are:
(1) Best is to use a single repository for all projects. Externals
would work but shared dependencies are an issue (see below).
(2) Shared dependencies (e.g. common code libraries) can live at the
same level as the projects.
(3) Third-party dependencies can live in a "vendor branch".
(4) Create a "production" and a "testing" branch for each project and
base the working folder on "testing". Copy from "testing" to
"production" when tested. Build the distribution from "production".
The testing folder is like a Tag (except that it can be continually
overwritten) in that it can pull files from different places in the
repository and create a folder structure like the one the end user of
the app would see. Is there a "real" name for this in official or
unofficial SVN talk?
(5) Version numbers should NOT be confused with SVN revision numbers.
Use folder names and/or Properties to store version info.
(*) No answers to my automation question (i.e. how to store "macro"-like
SVN operations that are used over and over, e.g. to build a testing
version). I guess I will work something out using a combination of
batch files, Python, and TortoiseSVN...
Nick Seigal
www.nickseigal.com
Advanced GIS Application Development
RESPONSES...
--------------------- [William Nagel] -----------------------
Hi Nick,
> Thanks in advance o' gurus of subversion (subversives?),
>
> I have a software project I am developing and want to put into SVN. I
> have some questions, but even after much time spent absorbing the
> literature, I still don't have any clear answers.
>
> 1. My project has dependencies such as third-party code libraries.
> Where does one typically store these in SVN? Without them stored in
> SVN, my "Tags" would not include them and so I could not be guaranteed
> of being able to exactly recreate the tagged incarnation of my
> project.
Take a look at "Vendor Branches" in the Subversion book.
>
> 2. Is a "working copy" considered a copy where the project is
> supposed to work (i.e. run)?
Nope. It's just a local copy of some (or all) of the files in a
repository that you can "work" on.
> If I create a working copy using the
> typical trunk/branch/tag structure and this working copy is also built
> from multiple repositories for its different components, then some of
> SVN's rules get in the way: I can't check out to a non-empty folder,
> so I can't check out both ./calc/trunk/calc.exe AND
> ./math/trunk/math.dll to my C:\Dev\MathCalculator local folder. But
> this is how the app is supposed to be and this layout is not
> particularly unusual...am I missing something here?
Working copies can only be built from a single repository, sort of.
There is a workaround that might be a viable solution in your case.
See the "svn:externals" property.
>
> 3. If a "working copy" really just means a local copy, mirroring
> the structure of the various repositories from which it is built, then
> I
> have to have some redundant folders and processes for copying files
> locally to get a true testable copy. If my project is large, then I
> must have a place on my HDD to store (1) the testable copy, and (2)
the
> working copy. Then whenever I need to test, I need to copy files from
> (1) to (2) and probably unregister/register any *.dll files. I can't
> just tweak my code somewhere and then run from my development IDE to
> debug it. Do I REALLY have to rewrite my app to support the SVN
> limitations? Shouldn't SVN be architecture agnostic?
Again, it sounds like svn:externals is a possible solution for what you
want to do here. Either that, or you could have a "testing" branch and
a "production" branch. Then, once you've tested a change you can merge
it over to the production branch.
>
> 4. What is the standard practice for building up a working folder
> hierarchy out of multiple repositories? Do people use some sort of
> script or batch file to store the sequence of commands to checkout,
> update, etc. Essentially, I want to tag _across_ multiple
> repositories (meta-tag?).
It sounds like what you really want to do is have a single repository
that is organized with top-level directories for each project you have.
That way, you can easily copy/merge between projects and create
branches/tags that span projects. You can always check out just one
project by pointing the URL to a subdirectory of the repository. For
example:
$ svn checkout http://svn.nickseigal.com/repos/NS2004
would check out the NS2004 project from the repository "repos", if
NS2004 resided in a top-level directory called NS2004.
>
> 5. If copying a file is a commit and a commit changes a the
> revision number of the database, does tagging also change the revision
> number? This would be bad. If tags are to be part of the same
> repository with the trunk, but they shouldn't affect the revision
> number. The same applies to branches. Or am I getting software
> versions and repository revisions mixed up here?
Repository revisions have nothing to do with software versions.
They're simply a reference to distinct states of the repository. Every
atomic change you make to the repository will increase the repository
revision by one. If you want to store software version numbers with
the files, you might want to look into properties.
>
> 6. My app is made up of code, data and documentation. These all
> change and have their own version numbers, as well as variations. For
> example:
>
> NS2004 - GENERIC RELEASE
> (a) NSApp v1.0.3 (.exe)
> (b) NSDatabase v5.3.2 (.mdb)
> (c) NSUserGuide for NSApp v1.0.3 with NSDatabase
> v5.3.2
>
> NS2004 - CLIENT X VARIATION RELEASE
> (a) NSApp v1.0.3 (.exe)
> (b) NSDatabase v5.3.2 for Client X (.mdb)
> (c) NSUserGuide for NSApp v1.0.3 with NSDatabase
> v5.3.2 for Client X
>
> I understand that the generic release should be the "trunk", the
> client variation should be a "branch", and the releases should be
> "tags"
> but of what repositor(y|ies)? If they are each in a repository, then
> how can I "tag" the releases (i.e. where do the tags get stored)?
> Does the following structure make sense?
>
> http://svn/nickseigal.com/NS2004/
> ./trunk/App/
> ./trunk/Database/
> ./trunk/UserGuide/
> ./branches/ClientX/Database/
> (...)
> ./branches/ClientZ/Database/
> ./branches/ClientX/UserGuide/
> (...)
> ./branches/ClientZ/UserGuide/
> ./tags/App/v1.0.0/
> (...)
> ./tags/App/v1.0.3/
> ./tags/Database/v5.3.0/
> (...)
> ./tags/Database/v5.3.2/
> ./tags/Database_Client/v5.3.2_ClientX/
> ./tags/UserGuide/App_Database/v1.0.0_v5.3.0/
> (...)
> ./tags/UserGuide/App_Database/v1.0.3_v5.3.2/
>
> ./tags/UserGuide/App_Database_Client/v1.0.3_v5.3.2_ClientX/
>
> I am still trying to fit in my shared dependencies, third-party
> dependancies, InstallShield build files, dev notes, etc. into this
> structure. Any tips are very welcome!
Yes, that structure seems to make sense. If you decide to move all of
your projects into a single repository, then I'd suggest moving that
whole structure into a single top-level directory for each project.
Like this:
http://svn.nickseigal.com/repos/
./NS2004
./NS2004/trunk
./NS2004/branches
./NS2004/tags
./Project2
./Project2/trunk
./Project2/branches
./Project2/tags
Shared dependencies can then be placed in their own top-level
directories, or in directories under a ./vendor directory (or somewhere
else that fits your fancy, Subversion doesn't care). You can use
svn:externals to mix and match projects in working copies.
Subversion doesn't allow copies between repositories (at least not in
any practical fashion for what you want to do), so your tags directory
will have to be in the same repository as your trunk for a given
project.
Hope this helps,
- Bill Nagel
--------------------- [Michael Ching] -----------------------
Hello Nick,
I'm sure people on the list might have some better suggestions, but
hopefully this is helpful.
Overall it sounds like the simplest thing would be to use one repository
since you seem to have quite a degree of dependencies between
components.
>I have a software project I am developing and want to put into SVN. I
>have some questions, but even after much time spent absorbing the
>literature, I still don't have any clear answers.
>
>1. My project has dependencies such as third-party code libraries.
Where does one typically store these in SVN? Without them stored in
SVN, my "Tags" would not include them and so I could not be guaranteed
of being able to exactly recreate the tagged incarnation of my project.
>
>
This might help a little. It is the recommended way to handle this
situation. http://svnbook.red-bean.com/en/1.1/ch07s04.html
>2. Is a "working copy" considered a copy where the project is
supposed to work (i.e. run)? If I create a working copy using the
typical trunk/branch/tag structure and this working copy is also built
from multiple repositories for its different components, then some of
SVN's rules get in the way: I can't check out to a non-empty folder, so
I can't check out both ./calc/trunk/calc.exe AND ./math/trunk/math.dll
to my C:\Dev\MathCalculator local folder. But this is how the app is
supposed to be and this layout is not particularly unusual...am I
missing something here?
>
>
Working copy derives its name from the fact that it is the copy that you
are doing work on.
In general this sounds like a place you'd usually use externals. You'd
need to slightly change the layout of your files, though, so that each
external can live in its own subdirectory.
svn:external
bin/ http://svn.nickseigal.com/calc
dll/ http://svn.nickseigal.com/math
To preserve the directory structure you want you could then symlink
things to the place you want them. Subversion can safely version
symlinks like normal files, but unfortunately this solution will not
work on Windows.
>3. If a "working copy" really just means a local copy, mirroring
the structure of the various repositories from which it is built, then I
have to have some redundant folders and processes for copying files
locally to get a true testable copy. If my project is large, then I
must have a place on my HDD to store (1) the testable copy, and (2) the
working copy. Then whenever I need to test, I need to copy files from
(1) to (2) and probably unregister/register any *.dll files. I can't
just tweak my code somewhere and then run from my development IDE to
debug it. Do I REALLY have to rewrite my app to support the SVN
limitations? Shouldn't SVN be architecture agnostic?
>
>
>
Using externals you should be able to create a working copy that holds
everything you need. You can also have files in your working copy that
are not versioned if your testing requires them.
Another solution is to use make a testing area that symlinks its files
to the working copy, but again this is not easy under Windows.
>4. What is the standard practice for building up a working folder
hierarchy out of multiple repositories? Do people use some sort of
script or batch file to store the sequence of commands to checkout,
update, etc. Essentially, I want to tag _across_ multiple repositories
(meta-tag?).
>
>
>
Externals let you build up a heirarchy from multiple repositories, but I
do not think it will let you tag across them. You could do something
like set a custom property on the external folder which contains the
revno that the repository should be in. You could script something to
update it to the correct repository from there.
>5. If copying a file is a commit and a commit changes a the
revision number of the database, does tagging also change the revision
number? This would be bad. If tags are to be part of the same
repository with the trunk, but they shouldn't affect the revision
number. The same applies to branches. Or am I getting software
versions and repository revisions mixed up here?
>
>
Anything that needs to be commit (tags included) will bump the revno.
For the most part this shouldn't really bother you. The tag name will
usually contain the software version and the repository assigned version
number will not be important in general.
>6. My app is made up of code, data and documentation. These all
change and have their own version numbers, as well as variations. For
example:
>
> NS2004 - GENERIC RELEASE
> (a) NSApp v1.0.3 (.exe)
> (b) NSDatabase v5.3.2 (.mdb)
> (c) NSUserGuide for NSApp v1.0.3 with NSDatabase
v5.3.2
>
> NS2004 - CLIENT X VARIATION RELEASE
> (a) NSApp v1.0.3 (.exe)
> (b) NSDatabase v5.3.2 for Client X (.mdb)
> (c) NSUserGuide for NSApp v1.0.3 with NSDatabase
v5.3.2 for Client
>X
>
> I understand that the generic release should be the "trunk", the
client variation should be a "branch", and the releases should be "tags"
but of what repositor(y|ies)? If they are each in a repository, then
how can I "tag" the releases (i.e. where do the tags get stored)? Does
the following structure make sense?
>
> http://svn/nickseigal.com/NS2004/
> ./trunk/App/
> ./trunk/Database/
> ./trunk/UserGuide/
> ./branches/ClientX/Database/
> (...)
> ./branches/ClientZ/Database/
> ./branches/ClientX/UserGuide/
> (...)
> ./branches/ClientZ/UserGuide/
> ./tags/App/v1.0.0/
> (...)
> ./tags/App/v1.0.3/
> ./tags/Database/v5.3.0/
> (...)
> ./tags/Database/v5.3.2/
> ./tags/Database_Client/v5.3.2_ClientX/
> ./tags/UserGuide/App_Database/v1.0.0_v5.3.0/
> (...)
> ./tags/UserGuide/App_Database/v1.0.3_v5.3.2/
>
./tags/UserGuide/App_Database_Client/v1.0.3_v5.3.2_ClientX/
>
> I am still trying to fit in my shared dependencies, third-party
>dependancies, InstallShield build files, dev notes, etc. into this
>structure.
>
If this is all in one repository this layout looks fine to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 23 09:47:12 2004