[Mingw-users] DVCS for MinGW [Was: bash 4.x for MSYS?]

[Charles W. <cwi...@us...>]

On 6/1/2011 3:31 PM, Keith Marshall wrote:
> [Drifting off-topic]
> 
> On 01/06/11 17:20, Charles Wilson wrote:
>> This is ONE reason I'd really like to get an msys version of git
>> deployed (or another DVCS, but I'm familiar with git, and it seems to
>> have fewer currently-unavailable-on-msys dependencies than other tools
> 
> I'm certainly not opposed to the concept of a pure MSYS version of git,
> (AIUI, MSYSgit is really a MinGW(native)/MSYS hybrid);

I agree.

> however, given a
> free choice, I'd MUCH prefer mercurial.
> 
>> like mercurial which requires python).

I have no technical objections to hg, although I've never used it except
in "toy" repositories.  We already have a policy against *shipping*
anything we can't build -- see Console2.  That DOESN'T mean we can
officially support installation of a 3rd party tool, so long as we don't
ship the binaries ourselves.

If we were to support a third party hg installation, I'd definitely want
to standardize how it is accessed within a user's MinGW/MSYS
environment.  That is, like Console2, provide a mingw-get managed
package that contains a script, which in turn d/l's and installs it
somewhere private (/mingw/libexec/mercurial/{bin,lib,etc} ?
/mingw/local/ ?  We put Console2 in /usr/lib/Console2/), updates $PATH
and whatever other configury is necessary.

> The official Windows build requires a python DLL, (which is included in
> the distribution), not a full blown interactive python interpreter.

I didn't know that; the cygwin build requires (cygwin) python -- but
it's unclear, because the (cygwin) python DLL is in the same package as
the (cygwin) python interpreter.

I assume this "private" python DLL won't interfere with any other Win32
python interpreter (and DLL) installed elsewhere?

> It
> works perfectly well, unless we are going to adopt a policy that only
> tools we build with MinGW can be used for MinGW projects, (in which case
> I'd better abandon mingw-get right now, because every line of code in
> that has been developed on my GNU/Linux+Wine platform).

Oh, now you're just being hysterical <g>.  We do require that any
binaries we actually ship must be compilable using our system
(MinGW/MSYS) even if you, personally, don't actually do it that way.  I
can always take your packages -- like mingw-get/src -- and compile them
natively even if you don't.

I would have a problem if we actually shipped the hg binary package from
mingw.org -- unless we have a REALLY good reason (*)


(*) Err, hmm, alertdrv.sys  & QueueUserAPCEx + pthreads...
http://mingw.cwilson.fastmail.fm/QueueUserAPCEx-install.RELEASE_NOTES.txt
It's *optional* -- that is, not *needed* for pthreads -- but I'd like to
host this driver @ mingw.org...

>> If we had a DVCS, then the new repository for msys-2.0 that Earnie
>> mentions could be set up using that -- and git at least makes
>> tracking a remote branch, even one in CVS, much easier than cvs
>> itself.
> 
> I believe mercurial can do so too.  FWIW, I've been playing with all of
> hg, bzr and git since the CVS outage at SF, a few months ago; of the
> three hg is my first preference and git my least favoured -- in fact I
> find git to be quite repulsive

I just think it's funny that you're sensitive about that.  'Course, I
associate G.I.T. with my alma mater...and mercurial means
"temperamental, flighty, and unreliable" <g>

> both by name, and in use.  However, I am
> completely amenable to working with any CMS chosen by any project to
> which I wish to contribute, be it CVS, SVN, git, bzr, hg, SCCS or even
> some other which I have not previously used.

Me too.  I think git has mindshare, and it's also the lowest hanging
fruit in terms of how difficult it would be to provide a real MSYS
version.  So even if we go with hg for our future development, I still
plan to (slowly) pursue msys-git...and I have no plans to try to port
python to msys.

Now that I've finished the (initial) cygwin->mingw cross toolchain and
gotten that published, my next step back here in msys/mingw land is to
investigate LRN's tcl/tk port he posted a few months back.
http://thread.gmane.org/gmane.comp.gnu.mingw.user/35968

(and I'm way behind on updating some packages, both here and @ cygwin.
Sigh.)

For tcl/tk, my plan is to adapt some patches posted on the cygwin list
(which activate "unix-style" path handling while preserving the GDI
graphical nature of Tk rather than turning on 'X' graphics)...plus look
closely at what LRN has done.  Thus, we'll have an msys version of tcl/tk...

I'm not sure how to deal with the needs of native win32 gdb/Insight but
I'll cross that bridge later.  We might need both a msys tcl/tk AND a
fully native win32 tcl/tk (now that insight supports using non-bundled
tcl/tk/itcl/itk/iwidgets, that's definitely the way to go. Bundled=bad).

--
Chuck