Re: Cross compilation, warnings and errors

On Tue, Jan 25, 2011 at 2:09 PM,  <[email protected]> wrote:
> On Tue, Jan 25, 2011 at 12:15:24PM -0300, Luis Lavena wrote:
>>
>> cp file.ext to file.ext.orig
>> # edit file.ext
>> diff -u file.ext.orig file.ext
>>
>> There is a lot of manual overhead on that simple action. There is also
>> the lack of history of the changes or against which version/revision
>> was it implemented.
> ...
>> (and I forgot all my tricks to deal with CVS, sorry).
>
> Seriously, do you expect or even hope every project you deal with will adopt
> your favorite version control system?
>

No, I don't, I simply said that I forgot all my CVS tricks and asked
about the GitHub mirror with no answer, so I assume is not an
"official mirror"

> I think it's fine and wonderful you've learned to use git.  If you'd like to
> set up and maintain a git repository along the lines of what Brian did, or
> encourage him to bring it up to date, by all means please do so.
>

If the details on that particular setup were made public, for sure
others would have done it.

> But surely you agree that the choice of VCS is up to the people maintaining the
> project?  And surely you understand that changing VC systems is pure overhead?
> (There might be a return on the investment, but it's slow.)
>

Yes, I understand.

>
> I'm curious about git and Hg, but honestly afaict they solve a problem the
> FreeTDS project could only hope to have: tens or hundreds of contributors all
> merging their code.  We have one repository. It uses software installed on
> almost any machine that could build the project, and provides nightly snapshots.
>  It's about as accessible as it can be.
>
> And, no, I don't think the developer dearth is due to CVS.  No one's ever told
> me they'd love to contribute but can't stand dealing with CVS.  Hacking on
> FreeTDS requires relatively rare skills that can be applied to a wide variety of
> problems.  Why address those skills, and the time to understand the codebase, to
> something that basically works?  Think of the children!
>

Again, my comment was not aimed to get FreeTDS change to what you
think is my just learned or favorite VCS, but was with the idea of
hints about CVS workflow, seems these didn't read properly in english
after all.

As for the overhead, I'll refer to this just shown thread in the list:

http://lists.ibiblio.org/pipermail/freetds/2011q1/026688.html

There has been no official release of FreeTDS in the past 2 years:

http://www.freetds.org/news.html

But only nightly snapshots and stable ones. There is "stable"
snapshot, and while the directory inside the package is versioned, the
file itself isn't

I mean, i can go and download stable now, come back 2 months from now
and "stable" will not be the same, so my patches or my assumptions are
gone if I compare them with a MD5 or SHA1 signature.

So, if I were a developer working on a package manager attempting to
create a recipe (which, ehem, I am) I would doubt in the future that
my recipe will work and will need to keep a closer (real close) look
to FreeTDS project evolution.

Which brings the computer tools versus human doing the tooling for the
computers, but again, that is not the conversation I want to have.

As I simply stated at the beginning, my objective is able to compile
FreeTDS in order to compile TinyTDS to offer an alternative to Ruby
developers to connect to MSSQL servers, I'm not here to change your
VCS perspective or anything else, and if you thought I wanted, please
apologize.

Again, thank you for the indications on the issues related to headers,
will provide patches on SourceForge tracker to ensure successful
compilation against mingw-w64.

Regards,
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry