[Phpwm] Time management

[Dave Brotherstone]

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.

> 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.


> 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.

> ( 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.

Just my 2 cents :)

Dave.