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

Reply via email to