Let's say we currently have a legacy codebase that is having work done to it, and is being ported to new hardware. Currently version control is treated as only that and any work done on the code is through a series of zip packages that are turned into CM one at a time (as well as the test for it). When a release is prepared, the individual changes are dumped on top of the previous release with any conflicts resolved, then that code is run through this release's regressive test suite and it becomes the new release.
Our CMS currently just has the major releases available to pull down, and we have the individual changes available. We're talking about moving to some TFS-Git hybrid for the new maintenance cycle, since we can toss out the old system on which the code was compiled and changes managed (we want to work with Git as the dev repo, but since we've always used TFS that's what we will continue to use (and I'm hoping the guy saying that is thinking about using TFS for nightlies and CI and it really doesn't just stop at maintaining the status quo)). I've pulled down all the major releases and set them up as commits in a personal repo for now and work out of that, which is easy enough to do.
If I want to advocate for using Git or TFS as the primary method of tracking the changes, instead of code files attached to Word documents, I'd probably need to demonstrate we can do that. I've heard we can't move away from the one baseline for all changes and that the only way to track changes is to turn in the actual changed files as a package (can't wrap my head around that). Actually it's many people saying many different things as to why the process can't change, but it's going to have to with the new hardware, and I'd rather the solution not be half-baked.
So far, I've taken all the major releases from VMS CMS, taken the banner files (comments only files, a way to skate around writing an SDD) from TFS when we switched from CMS for just those, determined the sequence of events between them, and have a series of commits on one master with each tagged by release (save the commit for the banner version on TFS that is actually between two CMS releases, the source reference drive we use shows that release's banners didn't get captured).
I want to go back and make a branch out of each of those tagged commits, correct? Then rebase so each has the previous release as parent? At that point, to demonstrate that the change history can be captured, I'd branch off of a release for each change package we have archived for the child release. I'd then rebase the child release for every change package branch. I'd like them all to be at once, because for better or worse that's how we operate.
So my tree currently is just this...
*baseline
|
|
*release1
|
|
*release2
The tree would look like this...
*baseline
/ | \
/ | \
*chg0-0 *chg0-1 ...chg0-n
\ | /
\ | /
*release1
/ | \
/ | \
*chg1-0 *chg1-1 ...chg1-n
\ | /
\ | /
*release2
Can I reshape what I have into what I want? Can a commit be rebased as a merge of multiple parents? I seem to be able to insert history like that in a test repo I've set up at home but I haven't figured out the integration all at once step. Then again merging one at a time probably is still passable.
I only have so much time to 'goldbrick' like this at work, I'm busy writing functional packages at the moment. I'd love to have collaboration be more than pointing someone to my share on the network, regularly having to make "commits" by setting up a set of Beyond Compare sessions for each software component for that increment and dumping out the changed files and diffs there. There's only a few of us working on the code at a time but they make tools for this kind of stuff...
I suggest having a look at cms2git. I didn't see downloadable code but there is a useful description of the issues involved.