Migrating from VSS to Hatteras

re: Migrating from VSS to Hatteras

Steve Perry — Tue, 06 Jul 2004 19:19:00 GMT

We fall into catagory 2. We have 3 builds of a product for the most part are identicle. 1 is the base product that most people run. the 2nd one is a striped down version that the data entry temps use and is specifily optimized for fast data entry. the 3rd build is an specialized version for our audit department that has specialized searching and auditing modules. We have classes and forms that are shared across all three. Since we don't always build all 3 for every release (if the new feature does not affect one or more of the others). We are well aware that changes to the sare modules usualy break the other builds but fixing those is part of the preperation for releasing the new build. I have never used branching and merging but the big issue I see is that the person doing the merging must be very familar with all the changes, and if these changes have take place over a long period of time and by multiple developers, you are back to the same issue as sharing. To me sharing is very usefull and would be a huge loss.

re: Migrating from VSS to Hatteras

Chris — Tue, 06 Jul 2004 20:36:00 GMT

Thanks for the feedback, Steve.

I will make the 'claim' that you'd like the branch and merge model better once you got used to it, though I'm not saying I'm so sure of it that you'd be crazy not to do it. You're in that gray area where it's hard to say, in a vacuum, whether you'd spend less time fixing breaking changes with sharing, or less time tweaking a merge when applying it to your "one-off" releases.

If you don't mind my asking, about how many devs do you have (either touching the shared code, or across the 3 projects - whatever ballpark number you don't mind sharing)? I think people don't really have problems with sharing until the number of people touching the codebase passes some certain size, but pinning down that size isn't an exact science, since there are a lot of other variables, e.g. how much of the codebase is shared vs. project-specific, how many projects include the shared code, etc.

To contrast the lack of sharing, what features of Hatteras are you most excited about? Or, what limitations in VSS would you most like to move away from?

Chris Rathjen on Migrating from VSS to Hatteras

Rob Caron's Blog — Tue, 06 Jul 2004 22:59:00 GMT

re: Migrating from VSS to Hatteras

Steve Perry — Wed, 07 Jul 2004 03:23:00 GMT

There are currently 6 developers working on the project(s). Since this application has been around for 5 years (vb6) there have been as many as 10 developers. The core project contains 197 files of those only about 20-30 are not share with one or both of the other projects. The main project is on 1-2 month build/release cycles, the other 2 project can go anywhere from 3-6 months between build/releases.

As far as what features of Hatteras I'm excited about? The only thing I've read about is the intergration with the bug/task tracking. Intergrating the association with the files that change and the task associated with the change will be a great thing.

Thanks for the terrific blog, and fantastic information :)

re: Migrating from VSS to Hatteras

Chris — Wed, 07 Jul 2004 06:05:00 GMT

Steve,

I'm pretty excited about the Work Item/Source Control integration as well. In fact, I worked on Currituck, the work item tracking project, in the earlier stages before moving to Hatteras, and I've "rolled my own" bug tracker at a previous company, so I can tell first hand how nice it'll be.

I'm still convinced that helping move people interested in the Team System suite is the Right Thing To Do, but hearing people pining for pinning (heh) and missing sharing makes me realize we need to make that transistion as painless as possible. Part of that clearly needs to be a "So you like sharing..." document that helps ease the transition into the branch/merge model. I think branch/merge has a reputation as an intimidating way to handle shared source code (in general, not just in MS land), and that's something we'll have to tackle.

When I discussed the sharing issue today, someone else mentioned reorganzing the source tree such that you only *need* one copy of the code that's shared. I assume you've considered and rejected that for one reason or another. I'm curious, if so - maybe we can address that blocking issue instead? The build system in Whidbey has some considerable changes from the previous releases, and so I'm wondering if there's a new flexibility there that might help.

re: Migrating from VSS to Hatteras

Steve Perry — Thu, 08 Jul 2004 19:18:00 GMT

I guess the one of the main problems with branching and merging today is that you have to start off sharing anyway. I also ran into a problem a couple of days ago, after reading you comments, I was presented with a problem in which I needed to update a web service that is in production, but we have made lots of changes that are in testing, and this change needs to go out right away. So I attempted to branch from a labeled earlier version. So Long story short, I did'nt do it right, got confused and ended up losing (deleted and purged) the most recent version of the web service. So what I'm trying to say is branching is not an easy to use or understand.
I will come around, but its just going to take a while.
Once again thanks for your time.

re: Migrating from VSS to Hatteras

Chris — Thu, 08 Jul 2004 20:21:00 GMT

Yeah - the fact that Hatteras doesn't use the sharing model will feel different for people coming from VSS, but your scenario is a typical reason why you *would* create a branch instead of a share - you can safely work on fixes to the production in a "release" branch while doing new feature work in the main branch (for example).

So, in your case, even if you didn't create it at the time, in Hatteras you can branch from a non-tip version (the one you labelled as the release version). Checkins to each branch do not affect the other (as they would with sharing); instead, you merge from one to the other to move changes between the branches.

For this specific situation, that sounds like that would be preferable to sharing, but there are plenty of situations where sharing is preferable (when you *know* you *always* want the changes in one branch to immediately take effect in the other branch).

I need to get a list of common usage scenarios worked up, and show how VSS and Hatteras treat each one - maybe that will help people decide which is right (or "more right") for them.

Shared files

David Chapman — Tue, 13 Jul 2004 03:33:00 GMT

We use shared files far more than we probably should but there is one scenario where it's invaluable: when we share a common file defining our file format. We have multiple products that read the same proprietary file format. If someone makes a change to this file in one product we WANT the other products to break if they haven't been updated.

re: Migrating from VSS to Hatteras

Anna-Jayne Metcalfe — Tue, 13 Jul 2004 16:33:00 GMT

The scenario David Chapman identified (common header files) is one we use heavily too...and one I personally don't think suits the branch/merge model at all. How does Hatteras cope with that scenario??

That said, in every other case where we've used sharing/pinning it's been because branch/merge is so poorly supported in VSS. Pinning is a nightmare in the VSS IDE.

One question: Does Hatteras truly support branched projects, or is it file orientated in the same way VSS is? For example, I'd like to see files added to a development branch automatically propagated to production branches when they are raised to the next project version...

re: Migrating from VSS to Hatteras

Chris — Tue, 13 Jul 2004 16:39:00 GMT

David,

Makes you almost wish Windows had symlinks, eh? :)

The scenario you put forward is one where sharing makes perfect sense, if pointing the multiple projects at the same *one* file just isn't possible or feasible (and I know that can happen).

re: Migrating from VSS to Hatteras

Chris — Tue, 13 Jul 2004 17:15:00 GMT

Anna-Jayne: Tough, specific questions - my favorite :)

Re Common files: Off-hand, it looks like Whidbey supports this by adding existing items with "Add as Link" from the add menu in addition to the normal Add (Add, as you probably know, copies the item even if you added it as an existing item).

A linked item stays wherever you added it from, but otherwise is treated as any other file in the project, *as far as I can tell* (I'm no Solution Explorer expert), can be compiled against, etc. You can only remove the link from the solution explorer, rather than delete or rename the item, but that's probably A Good Idea anyway, given that it's a linked item.

The answer to your project branch question is mostly yes and partly no. Bear with me.

We branch and merge items on a per-file basis, in terms of how we track item history. However, you can perform branch and merge operations from any level in a tree of files recursively. So, if the *server* tree structure of your project is such that the new items are under the project root, then yes, any additions would be merged (as branched items) when you merged the project's changes.

The reason I emphasized the "server" tree is the fact that you can remap the way the files are located on your client workspace to be different than they're organized on the server. Generally, that's something you wouldn't want to get too fancy with; it's a feature that (to use a popular saying in MS land) gives you just enough rope to shoot yourself in the foot with.

But, it can come in handy to help address your need (project-oriented branch/merge) - say you version some binaries that are stored in $/ProjectFoo/lib ($/ is the semantic for server paths in Hatteras), but the way your build is setup, you want them in c:\foo\bin\lib on your machine, instead of C:\scc\ProjectFoo\lib, where they'd end up by default. No problem - you'd just remap $/Project/lib to c:\foo\bin\lib in your client workspace (similarly to the way you'd override a child node's local/working folder in VSS). They'd still get branched/merged appropriately when you did a branch or merge of $/ProjectFoo to $/ProjectBar (for example).

My assumption, of course, is that the single-rooted tree makes sense for the server organization, and you'd only need to reparent items on the workspace for some practical reason (the nature of your build system, for example).

I have to admit that I have very limited experience with pinning, or (more accurately) the situations that prompt people to need it. I've found myself getting a specific version of a file and making it writable, so I don't sync newer versions - but I assume that's a pretty limited example of a pin-like situation, and a hack to boot. What's a better example of a situation/problem where pinning seemed like the solution?

re: Migrating from VSS to Hatteras

Chris — Tue, 13 Jul 2004 18:17:00 GMT

Oh, one other possibility regarding shared headers -

I don't know which version of Visual Studio introduced this, but Whidbey (at least) has a type of reference called a "Project Reference" - basically, referring to another project in the same solution, instead of a (usually external) .dll.

Would putting your commmon headers in one project, and creating project references to it from your dependent projects, work for you? I can imagine situations where it wouldn't, so it's not a loaded question by any means.

re: Migrating from VSS to Hatteras

Anna-Jayne Metcalfe — Wed, 14 Jul 2004 11:56:00 GMT

"Would putting your commmon headers in one project, and creating project references to it from your dependent projects, work for you? I can imagine situations where it wouldn't, so it's not a loaded question by any means."

Arguably that's the way to do it, but I would say that a team shouldn't *have* to change its project structure just to integrate a new source code control tool. As a VSS admin I know I'd not be popular if I suggested this!

Surely it wouldn't be too difficult for Hatteras to support reasonably close equivalents to the VSS share/pin capability - even if largely for the purpose of migrating existing projects/databases?

re: Migrating from VSS to Hatteras

Chris — Wed, 14 Jul 2004 16:27:00 GMT

Well, I realized later that the project re-org has all sorts of problems depending on what exactly you're trying to do (for example, now they're in a separate assembly, which probably isn't "better" and would quite likely be worse), and it gets more complicated still if we're talking about native instead of managed code, etc.

I fiddled around with the "add as link" approach yesterday, and that seems to work, though I'm sure there are drawbacks there, too (off hand, for example, I remember how contrived C++ include paths can be even without having to contend with links).

It's not really a question of whether it's "too hard" to provide sharing/pinning; it has more to do with the branch/merge model and the various ways that sharing "breaks" the model, in ways that end up frustrating users. It's something you don't tend to run into until team size grows. Well, that's indirect - in truth, it's the number of people touching shared items and the number of times and item is shared that governs how likely you are to get bitten by it.

Having said that, I wonder if there's a way to meet in the middle, perhaps using policies (that is, create a way to say "you can't share files normally" but allow users with certain permissions to share specific items). This is just stream-of-thought here, mind you. The problem is that one user's life might be made easier by having two items shared rather than just branched (to be merged between later); while another would find himself bitten by the "spooky action at a distance" aspect of sharing. To an admin or to either user, it's usually pretty easy to see which they'd prefer on a case-by-case basis; but the system lacks that context and insight.

It's something we'll keep working on, to be sure.

Team System -- good information...

crashBlog — Sun, 09 Jan 2005 22:40:00 GMT

Hatteras won't Share? NO FAIR!

Chris Rathjen — Fri, 22 Jul 2005 18:02:08 GMT

This has come up on my blog before, but since it came up in the forums again, I thought I’d point people...