Jump to content
  • Advertisement
Sign in to follow this  
Muncher

what are some good SVN practices

This topic is 4740 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I have just installed Subversion and can now put project under source control! Before i start randomly adding projects to the repository, i was wondering how people organise their projects within it. For example, i was thinking of having ->Root ->Libraries ->Classes ->Projects where libraries store dll/lib workspaces, classes would just hold a *.cpp/.h combination for a class (then any changes i make on a class would affect any project using them) And projects would have any large project im working on (ie/ 3dEngine1.0 or whatever) Anyway, i would really appreciate some guidence on how to use this thing efficiently; and learn of any good directory structures you may have used. Cheers Paul

Share this post


Link to post
Share on other sites
Advertisement
How about following the Subversion manual? What I mean is this:

\projectname\trunk
\projectname\branches
\projectname\tags

Then you place all your project's subfolders (like src and bin) inside the trunk folder...

Share this post


Link to post
Share on other sites
Hello Paul,

First off whatever works for you works :) But based on my experience with Subversion here are a few observations and suggestions.

Subversion recommends the following two directory structures:


Root
|--- branches
|--- tags
|--- trunk
|--- ProjectA
|--- ProjectB
|--- ‘normal working area for projectB’
Root
|--- ProjectA
|--- ProjectB
|--- branches
|--- tags
|--- trunk
|--- ‘normal working area for projectB’


Where the branches, labels and main directory have the following uses:

* branches - Contain stuff that has been branched from main line development.
* tags - Contain snapshots of the project(s) from particular times or states.
* trunk - Contain stuff from main line development.

So the first question you need to consider is whether you’ll be branching code for different projects independently. In my opinion, the first option is simpler and easier to use, but less flexible. (In my development use something like the first option)

My repository and directory structure is based around the idea that the smallest unit of reuse is a library (or DLL) This means if you want to (re)use a class or function you don't add the source file to your project, but instead include the library containing the source file into your project. All the files to build each library are keep together. However all the generated files (.obj, .lib, .dll) will be generated somewhere else, so it’s easy to see what is version controlled and what isn’t.

Within the trunk directory (and any of the other subversion branches or tags directories) I’ve the following directories: Src, Build, Lib and Run. Actually I’ve also got SrcExtern and LibExtern for external code and libs, but that complicates the picture a bit.

Where:-

Src – Contains all the project and source files. VC should be configured such that no files are generated here.

Build – Contains all object and program database files generated when building. The directory structure mimics that of the source structure (So objects are store in directories matching their project name.)

Lib – Contains all the lib files generated when building.

Run – Contains all the media and configuration for your game. And all the game executable and dll files. (NB: media files are version controlled, exe and dll are not)

I don’t version control any of my generated files, so the directories Build and Lib are not checked into Subversion (These directories are kept within the overall subversion directory structure so I could build for a number different branches/tags at the same time – each building to its own Build, Lib and Run directories)

Probably the easiest way to illustrate this is with a simple example, suppose the code is structured into two libraries (log.lib and core.lib) and one executable (pong.exe). Built from three VC projects (log, core and pong) and one VC workspace (pong)

I'd have something like the following directory structure:

...--- main
|--- Src
| |--- log
| |--- core
| | |--- core.dsp (project)
| | |--- core.h & .cpp
| | |--- entity.h & .cpp
| |
| |--- pong
| | |--- main.cpp
| | |--- game.h & .cpp
| |
| |--- pong.dsp* (project)
| |--- pong.dsw* (workspace)
|
|--- Lib
| |--- Debug
| |--- Release
| |--- log.lib
| |--- core.lib
|
|--- Build
| |--- Debug
| |--- Release
| |--- log
| |--- core
| |--- pong
| |--- main.obj
| |--- game.obj
|
|--- Run
|--- pong
|--- config and media files (version controlled)
|--- pong.exe (generated)

*Ideally these should be in the pong subdirectory, but I never got that to work.

Cheers,

Tom

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Don't use the default fsfs datastore! Subversion doesn't really scale that well and the fsfs is even worse as far as scalability than the bdb datastore; it's also more difficult to back up. Imagine your project gets really big and you have 100,000 checkins. If you're using the fsfs datastore you'll have 100,000 files in the same directory! That to me isn't acceptable; I still can't believe that they switched the default from bdb to fsfs.

I dumped subversion because it doesn't scale and switched to Perforce.



Share this post


Link to post
Share on other sites
I have the following structure:


/
|--- ProjectName
|--- Branches
| |--- Main
| |--- <more branches>
|--- Tags
|--- 1.0.0
|--- 1.0.1
|--- <more tags>

The reason I put the trunk (Main) in the Branches folder was to make all branches appear the same to simplify a tool I've written that can automatically check out and build my projects. It can also automatically create a zip of project binaries. Very useful in making sure stuff continually builds, as well as automating the process of packaging things up.

Share this post


Link to post
Share on other sites
Thanks TomH, so much help! And i agree, that libraries should be the smallest unit of reuse; but what happens in the event that 2 libraries use the same source file? That would mean that you have 2 seperate versions of the same file under source control in different projects. How do you make it so changing one automatically changes the other?

Also, does anyone use more than one repository? Is it a good idea to use seperate repositories for different types of projects?

bte, i've installed tortoise svn and it is great!

Share this post


Link to post
Share on other sites
bdb can corrupt and become locked on a hard-failed commit. bdb can't be taken from a Windows machine to a Linux one nor vice-versa. We started on a svn linux daemon and moved to an NT file-based one, so I made sure to use fsfs. Integration with the NT domain usernames is seemless with the later configuration (maybe it would work with Samba on the linux machine, but we had an NT server to use).

100,000 check-ins is the equivalent to about 273 man-years of active software development. You should make seperate repositories for different projects if this is a concern and/or start a new repository when you start on a new version.

We use a seperate respository for every project, and you can use branches to coordinate the transfer of files between different source control systems (beit another svn repos or something else). Not ideal, but better than manual merges.

We just have trunk & branches and just put tags in the branches directory.

Architecturally, you should never share a file between libraries like that; either merge them into one library, or make a third library with the common parts extracted. It doesn't have to compile to a lib either, it could just be core header files (e.g. types.hpp or compiler.hpp).

Share this post


Link to post
Share on other sites
BDB does work fine. Yes it can get locked up if something goes really wrong (server disc becomes full, power fails during a commit), but it won't become corrupted. The instructions on how to recover from failed transactions (in the manual) work.

A repository can be taken to a different platform / architecture by doing a svnadmin dump and load procedure, which again, is fully documented. Backups can be done by backing up the files, provided you don't do it during a commit.

The Apache Software Foundation have a SVN repository with 291398 checkins at the time of writing.

Some operations must be fantastically slow on there (log springs to mind), but checkouts / commits will still be fast enough, as they are totally* independent of repository size.

Mark

* According to docs. Obviously the OS filesystem won't be perfectly scalable O(constant) so it may have some effect.

Share this post


Link to post
Share on other sites
Quote:
Original post by markr
The Apache Software Foundation have a SVN repository with 291398 checkins at the time of writing.
But Apache did something that I would advise against: put all their software in one repository.
As TomH said, you should use what works for use, but I'd advise to put only projects that are related into one repository. That makes branching and merging a lot easier.

As for BDB or FSFS: I have used BDB in MySQL databases and had some corruption, but my use of FSFS is not enough now to honestly compare. And if a filesystem has problems with 100000+ files, maybe it's time to switch file-systems.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!