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
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Dec 22 16:53:58 2004