[Gambas-user] Control Backgroung/Foreground colour

John Leake jleake at ...3375...
Wed Sep 17 03:48:55 CEST 2014


Hi Jussi,
I hope I have clicked the right reply button.

I do not recognise the work flow you have annotated.  I think there are
many approaches that fit particular needs. Staging/non staging etc.

The most significant features are:-
1) SVN will not detect a corruption - with Git the sha1 hash will
confirm that your source is unadulterated no matter who you pull it from.
2) With SVN, all your eggs are in one basket - Linus does not (or need
to) back up the linux kernel because everyone has a copy.
3) With Git branching and merging are really cheap and hence very fast -
SVN fosters long periods of lone worker activity (during which there is
no source code control) simply because merging is difficult and you do
not want to commit half baked fixes because of the repercussions to
other users by forcing more merges on them.
4) With Git you can work on the source without having a connection to
the server and still remain protected by source control.

But hey I am a long long way from being an expert watch the 2007 video
if you have an inclination and an hour to spend.

To me it works best through a good Gui client or when it is part of your
IDE (I am used to Jetbrains).  But if you are a command-line junkie then
fill your boots.

On 17/09/14 02:19, Jussi Lahtinen wrote:
> With svn you just checkout, edit the source if you want, and then compile.
> But with git, it requires something very different...
> git clone <the address>
> git checkout pristine-tar
> git checkout upstream
> git checkout master
> git-buildpackage -us -uc
> 
> I don't know what those commands do, but they were advised and obviously
> required (intuitive tryouts failed). Applying or creating patch was even
> more mystical, and I never learned how to do it so that it would work
> consistently. You couldn't even compile locally edited sources without some
> mystical commands (why??). Also simply updating the sources failed several
> times, and every time I had to rm the source folder and "checkout" again to
> solve the mess.
> 
> I don't know the reason for the whole mess, but I guess part of it was from
> the badly managed git repository. However, I have never seen such problems
> with svn. And yes, I believe that git has powerful features and certainly
> you can learn to use it, but is it really worth it? Couldn't these, at
> least essentially, same features be implemented with intuitive interface?
> There are a lot of alternatives.
> 
> 
> 
> Jussi
> 
> 
> On Wed, Sep 17, 2014 at 3:19 AM, John Leake <jleake at ...3375...> wrote:
> 
>>> Do I have to question my understanding of criticism? I really think this
>>> is criticism and where I come from this is nothing bad. Especially if the
>>> criticising person does it the conciliatory way :-)
>> Thank you.  Here, many will take their bat home if an outsider expresses
>> an alternative view to those that have invested an enormous amount of
>> time and effort in nurturing their baby.
>>
>> Also I know there is a huge potential for generating negative semantic
>> friction when there are language barriers. I bow down to all that are
>> bilingual/multilingual. I am only multilingual in the computer language
>> domain and I am too old to make up for that deficiency now.
>>>
>>>> I will guarantee that all newbies would feel this way.
>>>>
>>>
>>> That is a strong claim! No chance there is someone who does that twice
>> and
>>> just accepts the way it works now? Maybe they'll realise that this
>> happens
>>> only for input boxes which are read-only when time is right :-)
>>>
>> Yes I understand your point of view and I am sure that many will but I
>> think that many more will not. The young and nimble are like sponges to
>> new ideas. It is my observation in life that the more intelligent one is
>> then the less likely they are able to see the obvious (that was a
>> compliment by the way). Others who are old (and have to switch between
>> many IDE's/languages and wrestle with all sorts of quirks) see it as an
>> unnecessary pain. I am 100% confident users that are not computer
>> language geeks but know that double clicking on some text means that it
>> is highlighted and what they do next will replace that highlighted text.
>>
>>>> So what are we to do ?
>>>>
>>>> I think you have climbed to great heights of achievement and I like the
>>>> overall architecture but I will not accept your response to this
>>>> fundamental point of usability and what's more I could not live with it.
>>>>
>>>> If you are happy to guide me along as you have so far (and I thank you
>>>> for all of that) I am happy to find bugs in your code in return.  If you
>>>> do not accept my input as being a bug then that is your right and I am
>>>> fine with that.
>>>>
>>>> I am in the process of importing the repo into git so that I can work
>>>> independently and you are welcome to clone it and explore what I have
>> done.
>>>>
>>>> Still friends ?
>>>
>>> I don't think there would be a problem on Benoit's side to grant you
>> write
>>> access to the svn repository. If that's a problem for *you*, I'm sad to
>> say
>>> that, if your changes are good, you kind of put people into the hassle of
>>> seeing them through and importing them on their own. I can already see
>>> myself looking at your tree once a day in that future which I know I
>> won't
>>> have time for...
>> Thank you but I have done SVN and it really is cumbersome when it comes
>> to merging. As a result it does not fit very well with open source
>> projects. Git is tricky to get your head around and I am no expert by
>> any means.
>>
>> SVN with a Trac web interface was my choice also as technical director
>> in my own business however when you use Git there is zero fear
>> associated with allowing any number of strangers (with wildly differing
>> abilities and views) to interact and share ideas. Mecurial is an
>> alternative if M$ has any significance.  Check out Linus and form your
>> own opinionS (2007!).
>>
>> https://www.youtube.com/watch?v=4XpnKHJAok8
>>
>> As for once a day, I should be so lucky as to have something interesting
>> to look at.
>>
>> Just treat it as a branch that is hard to merge, not a backward step as
>> I see it. If your community were to consider a switch then there are
>> some good transitional examples that ran live right throughout the whole
>> migration process. I will certainly make public my experiences.
>>
>> Hey it might just be too much for me an I will just wither away.
>>
>> Things should not be a hassle if you are importing perceived improvements.
>>
>> Should I call it Gambas-for-ideots ?
>>
>> I hope to continue the collaboration.
>>
>> Best regards,
>>
>> John Leake
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Gambas-user mailing list
>> Gambas-user at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gambas-user
>>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
> 




More information about the User mailing list