Forwarding to list for further discussion, mail was sent to me privately though I can't see why. Must have been inadvertent.
-------- Forwarded Message --------
Subject: Re: [fossil-users] Conversation with a CM guy
Date: Mon, 16 May 2016 15:34:02 -0400
From: John P. Rouillard <rou...@cs.umb.edu>
Reply-To: rou...@ieee.org
To: Andy Goth <andrew.m.g...@gmail.com>
Hi Andy:
In message <5ae8586a-678d-2372-80f3-6804af670...@gmail.com>,
Andy Goth writes:
>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.
> [...]
>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,
Not totally unreasonable.
> [...]
>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.
Also I have been playing on and off with implementing the gitflow
workflow using fsl. It allows me to restrict what direction merges
flow (e.g. integration -> feature branch are allowed, but release to
feature branch aren't). This sort of restriction I think helps reduce
the merge issue you are seeing.
It seems a lot of the integration issues are caused by svn. Merge
tracking was always one of svn's issues. It seems to have gotten
better, but I think the DVCS systems still do a better job.
> [...]
>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 would like to see your document when you think it's ready to share.
In my case I have perforce rather than clearcase.
>Of course, none of that matters since he started by prioritizing marketing.
Well nobody ever got fired for choosing git (yet). Did you mention to
him that you can import a fossil repo into git if it turns out there
is some killer feature that only git has (although it sounds like
rebase is his killer feature).
I wonder if a git-fossil (like git-svn) might be helpful for people?
Have a great week.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
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
