[Phpwm] Time management

Sun Apr 17 09:49:09 UTC 2011

Dave Brotherstone wrote:
> On Sun, Apr 17, 2011 at 9:37 AM, Lester Caine<lester at lsces.co.uk>  wrote:
> [snip]
>> The current time wasting comes in where projects have 'improved' by
>> switching to git and personally I am finding that it is just a retrograde
>> step since many of the good things about CVS/SVN are ignored in the drive to
>> make 'building' code a lot easier. Since we do not 'build' php applications
>> as such, git just seems to get in the way.
> I'm not sure git has anything particularly to do with "building" code.
>   Have you got examples where git is more focused on building that
> version control?  For me, I can't obviously speak for others, but SVN
> gets in the way far more often than git does, and I use both on an
> almost daily basis.  Total cost of branching in SVN is much higher
> than git (not significantly on the branching part, but the switching
> and merging back etc) - hence the reason why git users often branch
> for even a tiny fix, but SVN users tend to only branch for a major
> feature.
> I'd like to commit my work on the bug fix before I go home for the
> day, but I can't with SVN because it's not finished, and it would
> break the build.  I'd like to save where I am, go back to the start
> point, and try a different approach - with SVN that's either a copy wc
> to a branch (which takes a while on a big tree), switch back to the
> trunk/branch I was on (which also takes a wihle on a big tree), create
> a new branch, switch to the new branch (also a while).  On git, that's
> either a commit, and a single command / UI click to switch to a new
> branch from a different start point (which takes a matter of a couple
> of seconds even on a big tree), or a stash (very fast) and create a
> new branch (effectively instantaneous - the time it takes to write a
> 41 byte file).
> On git, I can also commit/push before I go home.

Working on a single module in git is fine ... The main problem I find is that 
the CVS base has some 200 modules - alright 170 or so are probably legacy - but 
the porting over results in 200 repo's and as yet I can't get 'super-projects' 
to work in anything like the way that they do under CVS. SVN also messed up some 
of that as well which is why that move never happened.

I don't have any particular problem with the basic principle of git/hg - just 
that neither of them manage the whole problem - only the bit they are good at 
which is code within a single repo?

>> The main problem is that git
>> cross platform support is poor. Yes it can be used on windows but with a lot
>> of problems.
> Humm. Don't believe everything you read on the internet.  I use git
> almost solely on Windows, and TortoiseGit is now a very stable and
> full featured product.  Mingsys Git is also stable and mature.  Yes,
> there are I believe some "known issues" that still aren't supported in
> the mingsys version, but I challenge you to actually hit them with
> even advanced use.  I use the command line quite often, but I
> generally prefer a command line interface if it's intuitive enough, so
> that's says nothing against Tortoise.  It used to be the case that the
> tools for windows weren't as good, which is why if you do a search for
> git on windows you'll find hundreds if not thousands of entries
> claiming that windows support is "not as good" as linux support.  This
> (IMHO) is no longer true.
>
>> It is essentially a command line package, and integration into
>> Eclipse is only partially complete.
> I don't use Eclipse, so can't comment.
>
>>   with the windows version simply not
>> working the same as the Linux,
> Have you an example where the usage is different (today, not from
> 2008)?  And that usage could conceivably occur on a day-to-day usage
> basis?
>
>> and neither providing as transparent an
>> interface as CVS.
> CVS? Transparent?  Fair enough, if you like CVS and believe it to be
> good at keeping your versions safe, allowing you access to previous
> versions of your code, and allowing you to experiment on branches,
> then, well, I'm speechless.  CVS was great in it's day. But in
> comparison to Subversion, git, or hg, it's simply awful.
Actually you already ruled your self out from answering that. Many of the 
'complaints' about CVS are managed transparently by Eclipse. This handles the 
areas such as managing experimental work. CVS just provides the central base to 
nail down releases. Nailing down a release in git/hg is not nearly so easy and 
need separate cooperation from programmers? Until you define a particular repo 
as 'master' AND restrict who updates it ;) But then combining a block of repo's 
still has a number of problems and third port git tools don't even handle that 
at all yet.

>> Hg has proven to be a lot more 'windows friendly' and just as capable, with
>> hggit providing direct access to github and actually works much better on
>> windows that git's own third party tools.
> I only have a passing need for hg - to me, it looks the same as git, a
> little bit slower, and the command line syntax is more user-oriented
> (it comes from a what-do-you-want-to-achieve angle, as opposed to
> git's what-do-you-want-to-do angle).  Which one you prefer depends on
> whether you prefer driving or telling somewhere where to go.
>
>> Anybody got any ideas for a way forward? My own thought today is to simply
>> stop contributing back where a project has ignored the objections and simply
>> ploughed ahead with git or hg. Progress should at least be productive, but I
>> am not finding DVCS adds anything but obstructions :(
>
> For open source, there is absolutely no question that git/hg add far
> more possibilities - SVN is an obstruction to open source. Open source
> encourages sharing code, giving code back. SVN limits the people that
> can commit (in other words "give code back") to a list of known
> contributors.  If I want to work on an open source piece of code that
> uses SVN, I can't use SVN to commit/branch locally whilst I develop my
> new feature/bug fix/whatever.  I must submit a patch.  With git (and
> no doubt hg), I can work locally, share my changes, and they can be
> accepted or not into the project.  If not, the changes can remain open
> and merged with the current version (a patch goes stale, but my open
> repository stays up-to-date), and other people can use the changes if
> they like.  Or improve them.  I can then take those improvements.
> With SVN, that's a series of patches being passed around.
>
> An interesting measure of how good your source control system is is
> how often you comment out code.   If it's great, you'll practically
> never comment out code - you've got it, you know you've got it, and
> getting it back is trivial, if getting it back is hard, time consuming
> or impossible (because you haven't committed it yet), then in theory
> you'll comment out more often.
This is the whole problem nowadays.
My own code base is fully available via git AND hg, is cloned from other 
sources, and anybody can access it, but MY build of the php sites making up the 
project are somewhat different to other developers who are also doing their own 
thing. What I'm trying to nail down is how to manage a production release - or 
perhaps the days of that are gone? The whole point of my own developments are 
that each individual module of the whole CAN be updated independently so the 
single monolithic release may well now be obsolete?

>> ( And that is another 30 minutes wasted :) )
> Ah, I think occasionally stopping to sharpen one's tools can be well
> worth it, if you can then work faster. :)
>
> Note I've not got anything against hg - just that I got into git, and
> I've not read anything that makes me want to switch over and learn
> another new tool.
Trying to use EITHER with Eclipse is the problem and even the development teams 
of both keep saying "Perhaps you are better off with CVS". There IS a very good 
case for the master copy of a project being nailed down a bit more, and both hg 
and git can 'clone' from CVS so perhaps pushing a copy of a stable release back 
is an alternative management option? You still have all the flexibility of DVCS 
but with a stable production release process.

Mind you - discussion options is a little more helpful than "We are using git 
because github is great" - although if it allowed me to download a 'production 
super-project' of repo's as a single hit IN Eclipse then I would probably not be 
arguing :( Today that simply does not work ....

Perhaps we all need to scrap GUI interfaces and return to 'DOS'? I have no doubt 
that everything works fine from the command line - I keep being told that :)

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php