Today I had a conversation with the guy who handles the configuration management for the software project to which I'm on loan.
He mentioned that in a couple years he wants to switch away from the old version of Subversion they're currently saddled with. I suggested he consider Fossil since I have already successfully imported his 10K+ Subversion revisions to a private Fossil repository (with the help of my andygoth-import branch), and since it's been extremely helpful to me and the others from my organization on this project. In particular, it's proven its worth as a go-between linking his Subversion repository with our ClearCase repository, which are located on private networks at different sites, plus it allows offline operation on our laptops, captures development we do directly on the target device, and keeps it all in sync through network and file share links, whatever is available and when. A few weeks ago, he saw Fossil in operation as we spent a few hours untangling many months of failed and incomplete merges that were done simply by trading code snapshots which each side diff'ed and claimed to have incorporated, yet in reality they only took the half of the changes that appealed to them. Yet with everything in one place, Fossil enabled us to make sure it was all done correctly and completely with all parties in agreement. He said he thinks he'll go with Git instead because that would give the engineers working under him more forward mobility when they eventually move on to other companies, whereas Fossil is unknown and would not improve their employability. He also said he likes Git's rebase capability since he believes it will solve a merge problem he's been having with Subversion. The merge problem is when he tries to merge a feature branch into an integration branch, he also gets all the other stuff that's been merged into the feature branch to virtually update its baseline, even if that stuff has not itself yet been deemed ready to merge into the integration branch. The same goes for history research: all that extra is shown as changes on the branch relative to its root. He said that with rebasing, he can strip all the contributors away from the branch and focus only on what what changed in the branch itself, then review and merge only that into the integration branch. He admitted he hadn't actually tried any of this, had only just read about it. I responded by explaining to him how I handled these same problems in Fossil, how I have things organized to track our ClearCase, his Subversion, feature branches, and integration branches. How to merge just the pertinent parts even if things otherwise get out of order. How to handle pulling stuff into the Fossil branches that was externally added to ClearCase or Subversion. And so on. I'm writing an extensive document on this. I concluded by saying I think Fossil can provide what he's looking for. I also told him about the Git issues I've read about, particularly how fast and loose it plays with preserving history, how branches aren't much more than tags identifying the final product of a development effort. I said I can see how this benefits the Linux kernel requirement that the maintainers not be overburdened by the blow-by-blow history, how they're ultimately only going to want the final product. But I said that disregard for preserving detailed history, including (perhaps especially) mistakes, is anathema to me, how important it is that I be able to research the detailed development history when I'm tracking down when and how things went wrong. Of course, none of that matters since he started by prioritizing marketing. -- Andy Goth | <andrew.m.goth/at/gmail/dot/com>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
