Source Control and Sharing Projects

May 29, 2007 • from Hood River, Oregon • 28 comments

On this page:

Over the years I've been using source control kind off and on for my personal development. I would really love to use source control all the time but in the past I've had a number of issues in making things work correctly with the way I work on my internal projects. For work I do with customers I generally can use source control with no issues because projects are set up atomically with everything needed - all the various projects - parcelled out into a separate directory tree that's easily managed. However, for my internal work I tend to share a lot of library projects into the various top level solutions and I've never been able to get that to work reliably in Visual Studio.

Here's a little background.

Internally I've mostly been using SourceGear Vault and I've been fairly happy with it. Maybe the biggest thing that originally attracted me to Vault was that it was easy to get going and set up and work ontop of the .NET stack - it works with IIS and handles installation of server and client components for VS.NET with a minimum of fuss without having to drop to command line installs <s>. At the time the command line would have been a major frustration (ie. CVS, Subversion etc.).

The biggest issue with Vault has not been a functional but a financial issue. Pricing is reasonable for licensing (and a single individual license for 1 developer is free), but keeping up with the licensing year after year is getting expensive especially when rotating through users on a number of projects.

This weekend I also spent sometime looking at Subversion again for the first time since it was pre-release. As I'm working with another customer looking for a source solution I thought I should reevaluate and take another look at Subversion and spent the better part of the day installing and testing Subversion. It's come a long way in terms of installation pain and interoperability for Visual Studio (with the Ankh plug-in that works well).

Subversion worked very well, although the initial configuration of server and client took a bit of time to step through originally, as is to be expected when you are dealing with command line interface. Luckily there are several excellent walk-throughs out there that help you get started with setting up Subversion for operation with Visual Studio (the one that I like best is this one).

Subversion can run with its own built in distributed server interface which is small, lightweight and self contained which is great. But the built in server doesn't use HTTP and in order to run over a firewall friendly HTTP interface Apache is required. For SC connectivity on the road HTTP is pretty much a requirement and given that I run IIS on my server using Apache is not really an option (as you can't have both IIS and Apache serving port 80). So for me personally I'm going to have to re-evaluate whether Subversion is going to work out.

Sharing Projects

On a more functional level though I keep running into a problem with source control integrated with VS.NET that's been difficult to work around. This was one of the reasons I thought I'd give Subversion a shot as well, but it looks like the behavior of shared projects is somewhat similar to that of Vault (which may mean it's actually an issue with the VS.NET SCC provider). It's also quite possible that I'm simply ignorant of a feature to make this work a bit easier...

So here is the scenario that I'm dealing with. I have 4 different internal Solutions that I work on here regularily and each of these Solutions has a number of common 'framework' projects. Typically in my apps I have a UI project (ie. a Web or WinForms project), an app specific business objects project, and 3 separate projects that make up the business object framework, a utility project, and a custom UI control project. The latter 3 projects are basically attached to each of the solutions and changes made in one affect the other solutions potentially.

These reusable projects are what I call framework projects which means that they are fairly stable and any changes are carefully versioned in such a way as to not break existing code, so there's very little concern of changes in these framework projects breaking the other solutions. The process works well enough when not using source control.

In terms of physical layout of my development tree I have a base directory that most projects are stored in with subdirectories for each of the projects so for example I have:

c:\projects2005

WebLog

WebLogBusiness

Westwind.Web.Controls

Westwind.BusinessObjects

Westwind.Tools

WebStore

WebStoreBusiness

WebStoreClient

Westwind.Windows.Controls

...

WebLog.sln

WebStore.sln

Everything is in (I think) easily accessible relative paths so it's easy to move the code around as needed. The solutions are in the root path and they reference projects in the child paths. The project files are contained in the various project directories (except for stock ASP.NET projects which don't have a project file).

Now if I add source control into the mix, it always works just fine adding the first Solution to source control. With Vault when I add the project it will do all the work and create the source code repository subtree for me and add each of the projects as a child project. Subversion does the same sort of thing plus it flattens any directory hierarchies if the hierarchy involves distinct directory trees.

Once the single solution is under source control both Vault and Subversion work great with it.

So then once I open the second Solution (which is not under source control yet) I can see that the shared project now show up as under source control in VS.NET while the Solution itself and the main projects (ie. WebStore) are not. This is kinda nice - I get part of the way there, without doing anything <s>.

Unfortunately getting the entire Solution under source control now doesn't work with either Vault or Subversion. In Vault I get something like this:

Subversion/Ankh gets a similar although somewhat more descriptive error complaining about the Project2005 folder already being under source control. The issue is that both projects share the common root (Projects2005) in which the solution file is stored:

In Vault I can get this to work by manually adding the projects to the Solutions base subdirectory manually in the client explorer and while that works, it appears that something gets munged up between the VS.NET integration and Vault. While the Vault client sees changes I make to any source code in these manually added projects, the Vault client in VS.NET does not unless I explicitly check out the files - ie the automatic detection of changes to the source files is missing. (Correction - it looks like it is showing the updates, but it's inconsistent - apparently there's a refresh issue in VS.NET rearing its head again).

With Subversion and Ankh I'm not really sure how I can properly set up my second Solution. The first solution works just fine, but the second solution fails to load as did the Vault solution. So I use the ToroiseSVN to manually add the folders to the source code tree. The result in the Repository Browser looks like this:

which looks fine here, but looks like this in VS.NET:

IOW, it looks like Ankh/Subversion recognize that the directory is under source control, but it doesn't want to properly track it in VS.NET. Notice that the other shared libraries are showing up under source control from the first Solution that added these projects to source control. I'm not sure how to make Ankh properly recognize these files and the project at this point. <shrug>

So anyway, I'm not exactly very well versed with source control strategies so I could use some input on a couple of points:

a) Running Subversion on the Web
Anybody using Subversion internally on their servers and over the Web? Is there a way to somehow run on IIS (Web Dav maybe in some way?) What's the best solution for backing up repositories?

b) Sharing Library Projects
I'd think that the approach I've taken in setting up my shared projects in multiple solutions a fairly common scenario but I'm not really sure. Is this the best way to manage these projects this way? There are alternatives that range from setting the libraries up in a separate solution altogether to simply and simply not including the source of the framework projects in the application level solutions.

The Voices of Reason

Nick Parker
May 29, 2007

# re: Source Control and Sharing Projects

We've been using Subversion at work for over the past year and I love it. We run it using Apache without a problem. If you are going to use a Windows machine with Apache and IIS installed on the same box I would recommend you change the port configuration within Apache so it doesn't listen on 80. We had issues with the Ankh plugin and decided to go the route of TortoiseSVN and haven't turned back. As far as sharing projects goes, you should look into Properties, in particular svn:externnals:

http://svnbook.red-bean.com/en/1.0/ch07s03.html

For your structure within SVN, we go with a Projects root, followed by client name, and then client projects within each of those, but that's somewhat of a personal choice.

Rick Strahl
May 29, 2007

# re: Source Control and Sharing Projects

Nick thanks for the feedback. The issue I have with anything but port 80 is that you would still need a hole in the firewall to get at it which is an issue when I'm on the road. And frankly I'd like to avoid having to set up and maintain Apache on my live server, although if it's just for SVN it's probably pretty easy to get going. But as it is the IIS port 80 co-existance requirement is kind of the killer for SVN on my live server for my personal store I think.

Thanks for the tip on externals - that looks like it might do the trick...

James Gregory
May 30, 2007

# re: Source Control and Sharing Projects

I'm in the same boat as Nick, Apache along side of IIS. Didn't seem worth the effort to get it playing nice with IIS, but I've heard it is possible.

Regarding backups, like most source control systems, you don't really want to be backing up the physical repository. That could lead to all kinds of nastiness if your backup is done mid-commit, and you try to restore from that. The recommended method is to use the svnadmin tool, as so:

svnadmin -q dump repositoryName > backupFile

That'll dump the contents of the repository to a file, which you can then safely back-up externally etc... If you want to restore, use svnadmin load.

Rik Hemsley
May 30, 2007

# re: Source Control and Sharing Projects

Try VisualSVN. It's like Ankh but (IMO) better.

Sean Rock
May 30, 2007

# re: Source Control and Sharing Projects

Hi Rick

i've been using subversion on Win2k3 as a remote repository so i can get to stuff while away from the office. Subversion can run as a daemon or as a webservice, the later being how i run it so i can do this:

svn://0.0.0.0/Project1 <- a repository
svn://0.0.0.0/Project2 <- another repository

i have a batch file that will install/uninstall subversion as a windows service. if you want it i'll send it to you but it is in the manual i believe, or maybe i found it on the net i can't remember.

for backup i have winzip running on a schedule that just backs up the repositories daily, with ws_ftp downloading the backups to a local machine, again daily. maybe not the best way but it works for me. I'm not sure if the dump command will include the revision tree, comments, etc so i just backup the entire repository.

As a general rule i tend to go with 1 solution = 1 repository - but this is just my preference. And if i need code from another project ( a common library or something ) i'll just use the include feature.

Joe Brinkman
May 30, 2007

# re: Source Control and Sharing Projects

Rick,
I used to run both Apache and IIS on my dev box and did not have trouble getting it configured. Just set Apache to run on a separate port and it will play nice with IIS (it has been a couple years so I don't remember the exact config file changes).

Personally, I have given up on integrated source control inside Visual Studio. I have never had much success getting any SC to work properly since at least VB5. Since I rarely do single project applications that may be the source of my problem. I don't know. I just know that the source control standalone clients work without any problems while the visual studio clients inevitably leave me wondering whether my source is actually saved or not.

DuncanS
May 30, 2007

# re: Source Control and Sharing Projects

We have Apache running alongside IIS very happily with *both* on port 80 - but on separate IP addresses instead. Nice thing about this is that your firewall/routing is then quite straightforward. One little registry tweak we needed to apply beforehand so that IIS doesn't hog port 80 on *all* IP addresses was:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\ListenOnlyList
(see http://support.microsoft.com/kb/890015)

and then specify the "Listen" setting in Apache's httpd.conf, e.g.:
Listen 192.168.0.99:80

With Apache we also use "mod_auth_sspi.so" so that we simply log onto the repository using our Windows Domain credentials.

Bob Archer
May 30, 2007

# re: Source Control and Sharing Projects

Rick,

The way we do it is as you said. Break out your "framework" as a seperate solution. Set up a post build task to copy the binaries to some common place like c:\projects2005\lib\wwcommon.

In your other projects add DLL references rather than project references.

VS will still allow you to step debug through to FW code if you need to during debug. If you need to edit the FW while working on a project you can always open a second instance of VS.

As far as your source control issues, I have been using PVCS for years. It has the ability to files acress projects. I thought most source control could. But, like others we don't use the SCC integration.

One possible thing to try would be to remove the common projects from your app's solution before adding it to source control. Once it is added, add back the common projects that are already under source control. Not sure how this will work in subversion.

Have you tried TFS? I think a 5 user version is included in the MSDN subscription package.

BOb

Cullen Waters
May 30, 2007

# re: Source Control and Sharing Projects

So, your problem is that the VS integration creates additional files next to the solution files, that save the source control related state of the files. I think the extension for the file is .msscci or something like that. You're probably seeing refresh issues because you have multiple solutions in the same directory, under source control, that are writing to the same file, to store their state.

I'm going to see if I can find someone on the source control integration team at MSFT to help you out with this.

Winston
May 30, 2007

# re: Source Control and Sharing Projects

I second Nick's remarks about TortoiseSVN.

Background: My team and I have been using SVN both professionally and personally for several years now and *love it*. I always try to evangelize it to the MS crowd.

We bailed out on the Ankh plugin very early on and used TortoiseSVN instead. Like Nick, we never looked back.

I suggest that people ask themselves: Why do I want it to integrate with VS.NET?

We've found that VS.NET integration bought us very little.

I think the main reason for integrating source control with VS.NET is because it would be so cumbersome to check stuff out of VSS and then go back to the IDE every time I wanted to modify a file. However, the great thing about SVN is its "Copy-Modify-Merge" approach vs "Lock-Modify-Unlock" (VSS). Because of this, I never have to "check out" anything. I can modify anything I want. Because of this approach, it does not really matter whether VS.NET *knows* about the source control status of the file.

I just edit whatever I want, and when I'm done, I just go to the folder in Windows Explorer and use TortoiseSVN to initiate a commit from the top-level project directory. TSVN tells me everything that has changed, gives me a great diff/merge tool, and commits everything at once as a single transaction.

Really, if you haven't checked out TortoiseSVN, you absolutely must. It's fantastic.

Regarding repositories, I agree with Sean Rock. I create a separate repository for each solution. However, with svndump it's pretty easy to combine a bunch of repositories into a big one or vice versa, so you're not locked in if you need to change later. Either way, I usually use the "trunk, branches, tags" structure within the repository.

For our "framework" code, we store it in a separate repository. Dependent projects include the source of the "framework" solution via relative paths to the project file. For example:
\dotnet\projects\MyApp\MyApp.sln will reference 3 projects:

\dotnet\projects\MyApp\Model\MyApp.Model.csproj
\dotnet\projects\MyApp\Website (an ASP.NET website)
\dotnet\projects\Common-Framework\Web\Common-Framework.Web.csproj

Having MyApp and Common-Framework stored in different SVN repositories works great with TortoiseSVN, but I think Ankh had some issues with it (one of the reasons we dropped Ankh).

Regarding repository access (sorry this comments is getting so long), for you, it seems like you need to use Apache, but it can co-exist with IIS on port 80 if you use a subdomains / virtual hosts. In reality, only one would be on port 80 but would proxy requests through to the other. This is fairly trivial with Apache in front. Not sure how it would work with IIS in front. One of my coworkers uses Apache in front of IIS. He just passes the "www" subdomain through to IIS and hosts Subversion from an "svn" subdomain. You could probably work something out.

Winston
May 30, 2007

# re: Source Control and Sharing Projects

2 more quick comments:

One nice thing about SVN is all the cool (and free) tools that integrate with it. You might want to check out Trac and WebSVN, both of which give you a web interface to browse your repository, complete with RSS feeds. I use Trac for my personal projects and it's fantastic.

Also, when I was learning SVN, I found that the Help documentation that comes with TortoiseSVN is a fantastic reference for SVN itself. Easier to digest than the "svnbook".

Matt
May 31, 2007

# re: Source Control and Sharing Projects

Winston is right, running mod_proxy with Apache listening on port 80 and sending requests for anything other than svn. or /svn/ to the IIS port works wonders.

Geoff
May 31, 2007

# re: Source Control and Sharing Projects

Have you give team foundation server a try?

Douglas Osborne
June 01, 2007

# re: Source Control and Sharing Projects

Rick,

Have you taken Perforce for a spin - http:\\www.Perforce.com - especially in terms of branching and merging.

Best,
Doug

Rick Strahl
June 02, 2007

# re: Source Control and Sharing Projects

Thanks everyone for the great feedback!!! It's helped get up to speed on a few issues very quickly and resolve the project issues both with Vault and SVN.

re TFS: I ruled out TFS from the beginning because of pricing. The customers I deal with just don't have the budget to use TFS. On top of that is that TFS is a bear to set up as you have to run all sort of support functionality. That'd be Ok in a local network environment but for an internet hosted server I'm just not fond of loading up a machine with this much stuff to run source control. For my scenario TFS is a non-contender because of this.

Winston, thanks for the detailed discussion of how you do things with TortoiseSVN. I can see that things work well with this tool, but doesn't it get somewhat tedious to jump to Explorer to do your commits? I can't help but thinking that VS integration - even if it's just visual markers and commit functionality is a pretty big productivity enhancer (but not a deal breaker <s>)...

Jeff Donnici
June 03, 2007

# re: Source Control and Sharing Projects

Rick,

I didn't see this mentioned in other comments, but your "framework projects" issue can be addressed in Vault using "Shared Folders" in the Vault client. In the repository that contains them, you right click the project's folder, choose to Share it, and then select the destination location. You could do this for each solution that contains those projects.

Under the hood, there's just one copy of a shared folder -- so changing those files from any one location changes them for all locations. They just appear in multiple places... and have a slightly different icon in the Vault interface (like stacked folders or files).

We use this in the office for similar projects that are shared across our web and desktop platforms and it works great. Once it's set up, it's pretty invisible going forward.

The SVN experiences (and all the previous comments) are also interesting as that's what I've started to use at home and for personal/side projects. I really like TortoiseSVN a lot and having it integrated with Explorer is great (one less client to run). Some of the tips here (like the :externals option) are great.

The more I use it, the more I think I prefer the SVN/CVS style of working (edit->commit) over the SourceSafe (or Vault default) style of checkout->edit->checkin.

Winston
June 04, 2007

# re: Source Control and Sharing Projects

I've never found it tedious to switch to Explorer. I usually just type the path into the Run window. But now that you mention it, it really ought to be easy to go from VS to Explorer, so did a quick search and found this plugin on CodeProject, and it works great (caveat: been using it for 10 minutes):

http://www.codeproject.com/csharp/Explorer.asp

That said, there are a few gotchas that I have thought of since I posted that comment.

I should say that IDE integration is definitely useful, but I don't think it should be a deal-breaker. I'm happy without it because we've worked out a way to do things with SVN that has worked really well for us. For the most part we haven't missed the IDE integration.

Refactoring that involves re-naming or moving files can be a pain. But that's only if you want to be able to see the history of a file across all of the names and locations it has had. If you are ok with that, you can just refactor in the IDE, and SVN will think you have deleted and added files, rather than realize you were renaming or moving them (this is usually fine with people, as some source control platforms (vss?) do this no matter what). If you do want to take advantage of SVN's ability to track history across moves, copies, and renames, then you have to:

1. Rename / Move the file using TortoiseSVN
2. In VS, exclude the (now missing) original file from the project and include the moved/renamed file.
3. Then do your refactoring that renames your class / etc

This is a pain, and if I ever need to do heavy refactoring *and* have SVN track changes across moves and renamings, I would definitely want my refactoring tool to be integrated with source control, so I'd probably take another look at Ankh (I haven't looked at it in a while since development on it seemed to be very slow in 2006. Thought it was abandoned).

That's really the only time I miss IDE integration, and it's not really a big deal to me.

IDE support, I side, I'd like to reiterate that in a team setting, SVN's "edit -> merge -> commit" approach completely blows away the "checkout -> edit -> checkin" approach of VSS (haven't used Vault). Never having to wait for another developer to check something in is priceless.

Winston
June 04, 2007

# re: Source Control and Sharing Projects

That last line should have read "IDE support *aside*"

James Gregory
June 06, 2007

# re: Source Control and Sharing Projects

I think there are two sides to the integration being outside of VS. I can see how some people might find the change of scenery a chore, but I enjoy it, I've never had a problem with using TSVN. One of the benefits of using explorer integration, is that you don't need to have all your version controlled files in your VS projects. I manage resources, documetation and database scripts completely outside of VS now, which is just one less thing for it to get confused about.

To each his own though, there is an extension for VS that allows you to use some functionality of TSVN within VS. It's called VisualSVN and I think is around $50. From what I've heard, it's good.

Andy
June 08, 2007

# re: Source Control and Sharing Projects

I've got to say that I believe TortoiseSVN is the way to go. The VS source control integration has been way more aggravation than it's worth. I had a some problems with Ankh (similar to the problems with VSS) in the IDE and switched to Tortoise. By the way, using Tortoise and Ankh at the same time caused some problems for us; they ended up having different ideas about the state of the files. We've got all our code in a single repository with different trees for each project. The developers have local copies of code in the same structure as the repository (not required, but it is convenient) and references to shared code is just with relative paths (dll or project references.) Works great. We typically have 6 guys working on the same code at the same time; I usually use the TortoiseSVN "Update" command before tweaking a project and "Check for Modifications" tool when I finish. I like this better than straight commits because I can usually solve code conflicts right in our diff tool (BeyondCompare) before commiting my changes, which I think is much easier than resolving a conflict flagged by SVN. I have to say that SVN's merge is very good though.

Rick Strahl
June 08, 2007

# re: Source Control and Sharing Projects

The more I read here the more I tend to agree as I review the messages here. I can totally see that with any of the source control tools out there it is much easier to set up projects properly in the external clients - never a problem there. In Vault for example, everything always worked correctly with the external client and it was VS that was getting confused because of the Project/Solution file relationships (which surely is a thorny issue if you use projects in multiple solutions).

FWIW, Eric Sink sent me a note (and a very generous license upgrade) that Vault 4.0 shipped this week and he mentioned that Version 4.0 has substantial improvements in the Vault VS.NET integration client. I'll be giving that a try as well later this weekend. I have one client that's going with Vault 4.0 right now so that'll be good.

I'll also give TortoiseSVN another shot when I get a little more time to set things up...

Thanks for all the great feedback!

SteveC
June 13, 2007

# re: Source Control and Sharing Projects

I have to chime-in on the greatness of Subversion. It's well worth the initial setup time cost. I use it through Apache. SSL is enabled via client-side certificates (which have the additional benefit of giving me a portable access control solution), and Apache is published on a high port number, so it's about as secure as you can get when you have distributed/internet-facing users.

Tortoise+SVN is "unbeatable". Ankh with VSS has given me problems in the past, but Tortoise never has. I have WebSVN installed also in my setups because it is free, but greatly prefer Cenqua's FishEye for repository analysis - but that's probably overkill for what you want to do.

As far as structuring goes, I have tried a few different ways but prefer the mode in "the Subversion book" of trunk-branches-tags for generally-produced apps, with one Repository containing a single Project which contains a single Visual Studio Solution which contains n projects. When it comes to client-specific stuff, I just make a new Repository, so my overall SVN structure is relatively "flat". Access is faster and backup/recovery/portability is simple too.

Rick Strahl
June 13, 2007

# re: Source Control and Sharing Projects

Thanks Steve. I'm now up and running with Subversion using basically the approach you describe and it's working well. I agree looking at Tortoise some more that this is not a burden and come to think of it I think I actually like this approach of keeping source control out of VS - along with its solution/project boundary complictions - altogether.

One odd thing I did run into though is that SVN (or Tortoise) choked on duplicate directory names. I had a directory named Westwind.Tools as a top level project dir and in one of my libraries I have the same path and it wouldn't let me use that. I had to rename the path. No big deal but I wonder if that won't be a problem later with common subfolder names (especially in Web projects). We'll see... <s>

One thing that seems to be a bit painful is actually adding a top level (project) to source control with Tortoise - it seems it takes a number of steps back and forth to make this happen. I would have assumed that Add would take care of this but I had to first add the project dir, then checkout the project dir to get all the files synched and that usually failed. I then had to get back and manually add all the individual files. I suppose there's probably an easier way but with the 5 projects or so I imported I ended up having to manually import files because the directory level imports failed. <shrug> It's not a big deal but a bit cumbersome. Hmmm... the right way is probably to add the folder in SVN then manually add the files in the first place rather than trying to do the directory. Next time <s>...

jojobar
June 20, 2007

# re: Source Control and Sharing Projects

I stumbled on these inforrmative postings and would like to share my experiences too:

We have a product that is spread across 3500 files and 20 wap projects (vs.net 2005). Our developers work from home (DSL) and offshore (256KB speed). After a bit of struggle I could put VSS with internet connection. It worked fine to start with...

Then remote developers started complaining about slow "get all" (every morning developers come in and do a "get all" on the vs.net solution to make sure that all latest changes are in). It was taking about 20 minutes. So, I transferrred the vss database to a much faster internet connection machine(at our colocated server). Still the vs.net solution "get all" is taking 16 - 20 minutes. Maybe it gets all the files anyways and then compares them (not sure here... I thought the slowness was due to my slow dsl upload speed). So there is no way around it! or is there?

Few weeks ago I started exploring alternate strategies (TFS/CVS/Subversion) etc. I did not try TFS because you have to install a plethora of support tools (STS, SQL reports etc.) to get it to work which is not possible on our remote production server. So, I tried CVS with a third party VS.Net plug in (do not remember which one... but it had a funny name!). Now the "get all" on the complete project took 30 minutes!!! I guess subversion will also be similar. I haven't installed subversion yet, maybe I will try that too, what the heck!

I am not sure how my long "get all" problem be solved with subversion etc. We are not very experienced with source control other than VSS.

Rick Strahl
June 20, 2007

# re: Source Control and Sharing Projects

Uhm, if you have 3500 files and you're updating many of those I would think that the bottleneck is simply the fact that a bunch of that has to download. OTOH, are you really doing a get all or get latest changes? Once you have local copies you shouldn't have to reload everthing.

I don't have projects with anywhere this size, but I'm now running Subversion with the native service (ie not over HTTP) and I'm very pleased with performance and my typical 6 projects with a few hundred files is super quick.

jojobar
June 20, 2007

# re: Source Control and Sharing Projects

I apologize... I am doing only the "get latest version" not "get all", that is what vs.net supports. Even if I changed one file, get latest version takes the same amount of time.

Also I just noticed that "check in" takes (not always but when I have checked out a bunch of files... like 20 .cs files) 10 minutes or so.

This may be due to the fact that these files are probably downloaded to the local machine and compared (for automerge etc.)... I also confirmed that my upload speed is not that slow (512KB).

When I do get latest on 3500 files on the local source safe database, it takes less than a minute.

Thanks for your comment. Maybe I will look into subversion. Seems like there is no way to avoid apache...

jojobar
June 21, 2007

# re: Source Control and Sharing Projects

I played with subversion a little more from a free hosted account. It seems simple to use. We are here very used to "Lock-Modify-Unlock (+ merge)" model as Winston described above. We have made the development process so that the build person has the responsibility to make sure all files have been checked in and all statuses changed in the issue tracker before doing a build (which can be done easily by running a report on the source control). This is because the developers often forget to check in the files they are working on.

With Subversion and "Copy-Modify-Merge" model, the source control system does not know about the changes that are being made and there is a chance that some may get missed out of the build or extra effort needed to ask everybody whether they committed everything.

I am curious to know how others are getting around this. We have around 3500 source file in the product so things can go haywire unless simple procedures are put in place.

jojobar
June 25, 2007

# Finally Subversion is working...

Over the weekend I made the switch from vss to subversion. Here is what I found in case somebody else might be interested...

Problem
--------
We have a vs.net solution with more that 3500 files and because there are some remote developers, we had put the vss database in a colocation server. The "get latest version" took about 20 minutes over 1.5mb dsl (whether you changed any files or not!). Once in a while check-in took 20 minutes. Also, if you abort one of these processes then the database would have to be analyzed and cleaned.

Subversion
-----------
So I installed apache (on port 8080, I am yet to find out how apache coexist with iis on port 80) and subversion and spent the better part of the weekend figuring out how to:

1. Ignore files in tortoisesvn
2. How to put permission correctly in apache (directory level permission)
3. Do effective backup
4. Work seamlessly with visual studio
5. How to transfer old vss history and database in subversion

Result
------

1. "Get latest version" is no longer needed and subversion update takes a few seconds. Commit takes a few second too.

2. The import from vss to subversion database did not work. I tried at least three tools from the web. Finally I found that one of the reasons I could not import stuff was because vss has a bug and in certain conditions you cannot do a "ss.exe get" command on a particular version (this is due to the fact that there are lots of labels on the files). After searching frantically for a solution in MS forums and sites, I gave up. So we will keep the vss db also for history purposes.

3. For backup, what I did was to install apache and svn on a local server and run "svnadmin fastbackup..." on the colocated server (live server) every one hour. Then run a program called syncback to compress and copy the files to the local server via vpn (actually hamachi). Also do a similar daily and weekly backups. So if the co-location goes down, all I need is to copy the repository and apache files on the local database.

4. I found a simple menu expender for visual studio. It is at http://garrys-brain.blogspot.com/2006/11/visual-studio-2005-and-tortoisesvn.html and does not provide fancy icons etc. It just allows calling tortoisesvn commands from visual studio and it works fine!

I think we are all set, lets see if I ever need to switch back to vss again!

Thanks for your time and patience. Any comments are welcome.

Rick Strahl's Weblog