In message <4d41a0c9-37e8-1a0b-2120-99953b016...@gmail.com>, Andy Goth writes: >On 16 May 2016 15:34:02, John P. Rouillard <rou...@cs.umb.edu> wrote: >> I would like to see your document when you think it's ready to share. > >I can't, it's not mine to share. And even if I were willing to spill >proprietary information, the document is heavily tailored to the project >I'm working on, full of host names and engineer names and site names and >version names and internal process references and all that.
Fair enough. A lot of the doc I write professionally is releasable and supported as part of the open source effort at the companies I have worked at. However that's not the type of doc you are writing 8-). >I might someday write a more generic document on my own time. I'll >partially outline it below. > >> In my case I have perforce rather than clearcase. > >I've integrated Fossil with Perforce in pretty much the same way. The >secret is the "-keep" option to open. Create the checkout directory >using the other SCM tool, then use "-keep" to ask Fossil to manage it >without overwriting it. Then use "f checkout -force -keep" to go from >version to version while still not overwriting anything. > >[ very useful and interesting info removed ] > >Oh right, renames. I guess you're going to want to track those too. I >haven't thought about them much because the way we're using ClearCase >completely prevents rename tracking. Ok. Yeah renaming would be useful. I don't know how it's handled in perforce, but I assume some sed magic on some query option can provide the commands to mirror the renames across repos. >And now we're talking about having Fossil track copies too. Once again, >I don't know how to apply that to the process I'm outlining. Fair enough. >I'm not sure this is what you wanted to read about. Maybe you wanted >workflow within Fossil, like how to manage branches. That would also be useful, but we are using perforce streams so the same promotion/restricted merge mechanism can be enabled using fsl I think. >Or maybe you >wanted to know how to synchronize despite lacking end-to-end network >connectivity. No, not so interested in that 8-). >>> Of course, none of that matters since he started by prioritizing >>> marketing. >> >> Well nobody ever got fired for choosing git (yet). > >One person being fired for a poor decision is preferable to the whole >shop having to bear a long-term burden that eats their competitive >advantage and their morale, possibly leading to turnover or layoffs. I agree, but the same can be said about using Microsoft or IBM 8-). >> I wonder if a git-fossil (like git-svn) might be helpful for people? > >I don't know what git-svn is. It's a git command that treats an svn as an upstream repo. There is also git-p4 IIRC. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users