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.
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?
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?
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?).
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?
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!
Regards,
Nick Seigal
www.nickseigal.com
Advanced GIS Application Development
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Dec 22 06:51:01 2004