Two More Very General Consulting Question

[Novice]

Things are moving alone with respect to the contract that I mentioned in
another thread. We're still in initial discussions but it feels
promising. Two basic questions have come up.

--

First question: They are asking about my availability.

If the truth be told, I have nothing else on my plate right now except
looking for work and there is nothing in the short term future either.
I'd like to say "I can dedicate myself to your project 100% starting
tomorrow morning" but am concerned that this may make me look bad. They
might well get the impression that I am so awful at what I do that I
can't find any customers.

Is there a good way to answer the availability question that basically
says I can give them my full attention immediately without making me look
like I'm really inept?

--

Second question: They are asking for examples of Java work that I have
done.

Unfortunately, I don't have much paid work to show him. A complicating
factor is that, while I keep copies of the code I've written forever, I
had a hard drive crash a couple of years back in which I've lost a fair
bit of my code.

I can only recall doing two paying Java contracts so far.

The more recent contract I did got cancelled during the development cycle
due to cost issues and was never implemented. The non-disclosure
agreement for that work is still presumably in effect so I couldn't show
them the code which I still have even if I want to. I could contact that
customer and find out if the NDA is still valid and I'm sure I'd get a
quick answer. Should I do that?

An earlier example of paid code was a Java applet that I did as a
subcontract for a friend a while back. He had written a Lotus Notes
application and wanted an applet to do graphing of performance
characteristics of the customer's products. That Lotus Notes page was
gone the last time I went to the website several years ago so the applet
is also presumably long gone, replaced by something else. I didn't sign
an NDA as far as I recall but the friend who gave me the contract may
have. I can find out easily enough but the applet would be pretty crude
by any modern standards even if the NDA wasn't an issue. I hadn't been
coding Java long and Swing wasn't even out yet so it is in AWT. (I later
made a Swing version but it's never been run outside of my IDE.)

If unpaid work can constitute a reasonable example - and I personally
think it should - I did one decent Java application and a servlet for a
friend for an NGO he was involved in for free, strictly out of interest
in doing it. However, he left the organization shortly after that and
they abandoned the work I'd done when he left. I didn't sign an NDA for
that work but I'm not sure if I should feel free to show the code to
someone else. That's assuming I didn't lose that code in the crash.

Aside from that, all the code I've got which survived the hard drive
crash, is code I've written for myself that has never really seen the
light of day outside of my IDE or isn't likely to be of interest to him
since he wants an application, not a servlet. I've got a few complete
programs, most of which are not very good in terms of style and design.
Should I offer him the best of those?

Or am I best to confess my relative inexperience and hope for the best?

I haven't claimed any great expertise yet - and don't intend to - but I
don't particularly want to emphasize how little paying Java experience I
have either. What's my best way forward?

 

[Martin Gregorie]

An earlier example of paid code was a Java applet that I did as a
subcontract for a friend a while back. He had written a Lotus Notes
application and wanted an applet to do graphing of performance
characteristics of the customer's products. That Lotus Notes page was
gone the last time I went to the website several years ago so the applet
is also presumably long gone, replaced by something else. I didn't sign
an NDA as far as I recall but the friend who gave me the contract may
have. I can find out easily enough but the applet would be pretty crude
by any modern standards even if the NDA wasn't an issue. I hadn't been
coding Java long and Swing wasn't even out yet so it is in AWT. (I later
made a Swing version but it's never been run outside of my IDE.)

That sounds like a reasonable starting point. Being willing and able to
explain why you were dissatisfied enough with the AWT version to create
the Swing version and why it is an improvement sounds like a good plot to
me.

However, I'd strongly suggest that you don't mention the crash because
IMO losing anything in a disk crash shows a certain carelessness. Here
I'm assuming that you now have an adequate backup scheme that is used
regularly and rigorously and that, preferably, you also are familiar with
and use a source version control system for any code you care about. Can
you explain your backup and version control strategy if asked?

If unpaid work can constitute a reasonable example - and I personally
think it should - I did one decent Java application and a servlet for a
friend for an NGO he was involved in for free, strictly out of interest
in doing it. However, he left the organization shortly after that and
they abandoned the work I'd done when he left. I didn't sign an NDA for
that work but I'm not sure if I should feel free to show the code to
someone else. That's assuming I didn't lose that code in the crash.

Same comments as above.

 

[Novice]

That sounds like a reasonable starting point. Being willing and able
to explain why you were dissatisfied enough with the AWT version to
create the Swing version and why it is an improvement sounds like a
good plot to me.

Thanks for taking the time to make comments, Martin!

I've gone into the code since writing my post and found that I confused
two different applets. The one that I modified to use Swing was not a
paid applet; it was a little demonstration applet that I wrote for
someone to illustrate something we were talking about socially. It
eventually led to me getting a contract with him so it was well worth the
brief time that I spent on it but it's almost too trivial to show anyone.

That applet that did the graphing was considerably more sophisticated and
never got changed to Swing because I basically just drew on Graphics
context with drawLine(); there were no other GUI classes used beyond a
Redraw button and a checkbox that gave the user an option with regards to
displaying the data. (There was a lot of calculating going on within that
applet, especially with regards to scaling the graphs suitably, so it
wasn't a trivial applet by any means. It just doesn't do anything
terribly interesting in the GUI aside from drawing curves.)

However, I'd strongly suggest that you don't mention the crash because
IMO losing anything in a disk crash shows a certain carelessness.

I had the same concern. But that IS why I lost a bunch of my code. How do
I explain that lost code in the best possible way WITHOUT admitting to
the crash?

Here
I'm assuming that you now have an adequate backup scheme that is used
regularly and rigorously and that, preferably, you also are familiar
with and use a source version control system for any code you care
about. Can you explain your backup and version control strategy if
asked?

In all honesty, I am still just limping along in the hope that the drive
won't crash again. I have a considerably newer computer so my odds are
better than they were with the aging computer that crashed but that's
clearly no guarantee that I won't have another crash.

I still don't have an adequate backup strategy and I know of version
control but don't use it. I simply haven't had the spare cash to do
something about that. I hope to do something about that as I make more
money on contracts but it might be a while as I have some debts that need
to be paid off....

 

[Martin Gregorie]

I had the same concern. But that IS why I lost a bunch of my code. How
do I explain that lost code in the best possible way WITHOUT admitting
to the crash?

With difficulty, which is why I suggested you avoid mentioning it.

In all honesty, I am still just limping along in the hope that the drive
won't crash again. I have a considerably newer computer so my odds are
better than they were with the aging computer that crashed but that's
clearly no guarantee that I won't have another crash.

If there's a possibility of remote working in the contract this might be
an issue: if you're storing the contracted work on your own computer then
it *must* be backed up, version control or no version control. If the
client uses a version control system then you'll probably be expected to
use it too and that would most likely apply wherever you may be doing the
work. As there are a variety of version control systems, both proprietary
and Open Source, in common use you'll probably get away without knowing
the details of a specific one, but some familiarity with what they all do
and the common terminology would be useful. IMO doing a non-trivial
coding project without using version control falls into the same category
as writing C without understanding make or Java without knowing ant,
maven or an IDE.

I still don't have an adequate backup strategy and I know of version
control but don't use it. I simply haven't had the spare cash to do
something about that. I hope to do something about that as I make more
money on contracts but it might be a while as I have some debts that
need to be paid off....

In this day and age I'd accept a project backup scheme based on a cycle
of two or more SD cards. That is, provided the most recent backup is
somewhere offline, preferably in a fire safe or at least in a shed at the
end of the garden. It would be a pretty big project if its documentation,
source and test data wouldn't fit on a 2GB SD card - much bigger than a
one person job for sure.

I'm currently using USB disk drives for system backups and doing the
backups with rsync for speed. A 30GB backup to a blank USB 2.0 drive
takes 3-5 hours, but a weekly rsync run to capture changes takes under 20
minutes.

 

[Arne Vajhøj]

First question: They are asking about my availability.

If the truth be told, I have nothing else on my plate right now except
looking for work and there is nothing in the short term future either.
I'd like to say "I can dedicate myself to your project 100% starting
tomorrow morning" but am concerned that this may make me look bad. They
might well get the impression that I am so awful at what I do that I
can't find any customers.

Is there a good way to answer the availability question that basically
says I can give them my full attention immediately without making me look
like I'm really inept?

Main rule: don't lie. If you get caught lying then
you are most likely out - forever.

Besides the last 3 years has not exactly been an IT boom. Lots
of good IT consultants has found it harder than usual to find work,
so I don't think you being available right away will be that bad.

If you want to downplay the fact a little it until after they
have decided to hire you, then "I will be able to start soon" and
"I am sure that I can start when you need me" may postpone the
question about exact date until HR has to ask.

Arne

 

[Novice]

With difficulty, which is why I suggested you avoid mentioning it.

If there's a possibility of remote working in the contract this might
be an issue: if you're storing the contracted work on your own
computer then it *must* be backed up, version control or no version
control. If the client uses a version control system then you'll
probably be expected to use it too and that would most likely apply
wherever you may be doing the work. As there are a variety of version
control systems, both proprietary and Open Source, in common use
you'll probably get away without knowing the details of a specific
one, but some familiarity with what they all do and the common
terminology would be useful. IMO doing a non-trivial coding project
without using version control falls into the same category as writing
C without understanding make or Java without knowing ant, maven or an
IDE.

First, sorry for the delay in responding.

What you've said makes eminent sense. Having backups is something I'd
want if I were the client. I'm long overdue to have a proper system of
backups and versioning so now is the time to get into that. Part of my
delay in replying was starting to look at the tools available and
skimming some tutorials on the subject. So far, it looks like I'll use
Subclipse since it integrates nicely with my existing Eclipse set up.

In this day and age I'd accept a project backup scheme based on a
cycle of two or more SD cards. That is, provided the most recent
backup is somewhere offline, preferably in a fire safe or at least in
a shed at the end of the garden. It would be a pretty big project if
its documentation, source and test data wouldn't fit on a 2GB SD card
- much bigger than a one person job for sure.

I'm currently using USB disk drives for system backups and doing the
backups with rsync for speed. A 30GB backup to a blank USB 2.0 drive
takes 3-5 hours, but a weekly rsync run to capture changes takes under
20 minutes.

I'm thinking of storing my backups and versions offsite if I can find a
secure and affordable place to put them. Finding free webhosting isn't
too hard so maybe I can find something comparable for my code. Of course
I will want to lock it down pretty tightly so that others can't pilfer
it.

 

[Martin Gregorie]

I'm thinking of storing my backups and versions offsite if I can find a
secure and affordable place to put them. Finding free webhosting isn't
too hard so maybe I can find something comparable for my code. Of course
I will want to lock it down pretty tightly so that others can't pilfer
it.

Here's what I do, which may give you some ideas.

- everything I want to keep is under version control except web sites,
which are developed here under a local server and FTPed to the public
server, which therefore doubles as off-site backup.

- my version control repository is on an always-on server. There is only
one repository for all work done on my local network.

- the server does an automatic overnight compressed backup of its
filing system to a permanently online USB disk which is big enough
to hold several backups. It runs for 2 hours. The disk is unmounted
and spun down when not in use, so is unsafe against fires or big mains
spikes. Its prime purpose is protection against data loss by finger
trouble.

- on a weekly basis the filing systems of each machine on the local net
is copied to a second USB drive using rsync. Backup time is 10-20
minutes per machine. This disk holds a single backup per machine and
is kept in a fire safe.

The effect of this is they there is at least one online backup of
everything plus a second offline copy that is never more than a week old.

Total additional cost backups is the price of two USB drives. The backup
utilities (rsync, tar and gzip) are free. Backups are controlled by shell
scripts I developed to my own requirements and cron, the OS job scheduler.

 

[Roedy Green]

Is there a good way to answer the availability question that basically
says I can give them my full attention immediately without making me look
like I'm really inept?

Don't worry. They are thinking about themselves. Never once in the
last almost 50 years has anyone complained when I could start work
immediately.

As for showing work. Often you can't show work you have done for
others. They own the code and they consider it proprietary. See
http://mindprod.com/project/projects.html Timing may be tight, but you
can do such a project and show them not only the code but the how the
app looks to the end user. That your work looks presentable and runs
well is of far greater importance than someone paid you to do it.
--
Roedy Green Canadian Mind Products
http://mindprod.com
For me, the appeal of computer programming is that
even though I am quite a klutz,
I can still produce something, in a sense
perfect, because the computer gives me as many
chances as I please to get it right.

 

[Roedy Green]

However, I'd strongly suggest that you don't mention the crash because
IMO losing anything in a disk crash shows a certain carelessness. Here
I'm assuming that you now have an adequate backup scheme that is used
regularly and rigorously and that, preferably, you also are familiar with
and use a source version control system for any code you care about. Can
you explain your backup and version control strategy if asked?

see http://mindprod.com/jgloss/subversion.html
http://mindprod.com/jgloss/tortoisesubversion.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
For me, the appeal of computer programming is that
even though I am quite a klutz,
I can still produce something, in a sense
perfect, because the computer gives me as many
chances as I please to get it right.

 

[Roedy Green]

I simply haven't had the spare cash to do
something about that.

IT will set you back $6 a month if you don't host the SVN server
yourself.

See http://mindprod.com/jgloss/wushnet.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
For me, the appeal of computer programming is that
even though I am quite a klutz,
I can still produce something, in a sense
perfect, because the computer gives me as many
chances as I please to get it right.

 

[Tom Anderson]

Indeed it does.

see http://mindprod.com/jgloss/subversion.html
http://mindprod.com/jgloss/tortoisesubversion.html

I would say that in this day and age, it is no longer appropriate to
suggest Subversion. Subversion was the best tool available for a long
time, and it is still perfectly serviceable, but there are better tools
available now; projects using it can keep using it without worry, but
there is no reason for a new project, or a project adopting a new source
control system, to start using it.

The better tools i mention include this one:

http://mercurial.selenic.com/

And another popular one that i can't in all honesty recommend.

These tools are free, featureful, reliable, straightforward, portable,
widely used, widely documented, and interoperable with each other and with
Subversion (sometimes via bridges, otherwise via repository conversion).
There is every reason to use them, and no reason not to.

IT will set you back $6 a month if you don't host the SVN server
yourself.

See http://mindprod.com/jgloss/wushnet.html

It will set you back nothing at all if you don't host the Mercurial server
yourself:

https://bitbucket.org/

There is *no* excuse for not using source control at all, and there hasn't
been for years. There is now *no* excuse for not having an offsite backup
of your source control system.

tom

 

[Arne Vajhøj]

IT will set you back $6 a month if you don't host the SVN server
yourself.

There are free ones.

http://www.svnhostingcomparison.com/

Arne

 

[Arne Vajhøj]

I would say that in this day and age, it is no longer appropriate to
suggest Subversion. Subversion was the best tool available for a long
time, and it is still perfectly serviceable, but there are better tools
available now; projects using it can keep using it without worry, but
there is no reason for a new project, or a project adopting a new source
control system, to start using it.

VCS is an area where fashion often seems to overshadow
facts.

When SVN came out then CVS was suddenly so oldfashioned - you
could not use a VCS without atomic commits without being
considered stone age.

I have never seen an actual problem due to CVS not having
atomic commits. Or even read about. Maybe the problem was
not that important.

Today with hg and git then SVN is suddenly so oldfashioned - you
can not use a non-distributed VCS without being
considered stone age.

The distributed part is great for code that is being worked on
by completely independent organizations (read: large open source
projects).

But most people do not really have that need.

So hg and git are great tools. But there are actually
not anything wrong by using SVN or even CVS for most
contexts.

And knowing a specific software is actually a good
reason to continue keep using it.

Arne

 

[Arved Sandstrom]

VCS is an area where fashion often seems to overshadow
facts.

When SVN came out then CVS was suddenly so oldfashioned - you
could not use a VCS without atomic commits without being
considered stone age.

I have never seen an actual problem due to CVS not having
atomic commits. Or even read about. Maybe the problem was
not that important.

Today with hg and git then SVN is suddenly so oldfashioned - you
can not use a non-distributed VCS without being
considered stone age.

The distributed part is great for code that is being worked on
by completely independent organizations (read: large open source
projects).

But most people do not really have that need.

So hg and git are great tools. But there are actually
not anything wrong by using SVN or even CVS for most
contexts.

And knowing a specific software is actually a good
reason to continue keep using it.

Arne

I'm with you on this, Arne. You beat me to it actually. 100 percent of
the version control scenarios that I have encountered in business in
over a decade require a "central" or "master" repository and an official
keeper of the flame. Branches have to be strictly decreed and
controlled, lest anarchy result. If git or Mercurial were used in place
of SVN, the manner in which they'd have to be used would offer zero
benefits over SVN.

I agree that there are plenty of scenarios that benefit from a
distributed VCS. But a whole bunch don't.

AHS

 

[Joshua Cranmer]

I have never seen an actual problem due to CVS not having
atomic commits. Or even read about. Maybe the problem was
not that important.

When you are trying to do archaeology or rollback (say, bisecting to
find a regression range), the "not having atomic commits" suddenly
becomes a major dealbreaker.

 

[Tom Anderson]

//mindprod.com/jgloss/subversion.html[/url]
http://mindprod.com/jgloss/tortoisesubversion.html

I would say that in this day and age, it is no longer appropriate to
suggest Subversion. Subversion was the best tool available for a long
time, and it is still perfectly serviceable, but there are better
tools available now; projects using it can keep using it without
worry, but there is no reason for a new project, or a project adopting
a new source control system, to start using it.

VCS is an area where fashion often seems to overshadow
facts.

Today with hg and git then SVN is suddenly so oldfashioned - you can
not use a non-distributed VCS without being considered stone age.

The distributed part is great for code that is being worked on by
completely independent organizations (read: large open source
projects).

But most people do not really have that need.

I'm with you on this, Arne. You beat me to it actually. 100 percent of
the version control scenarios that I have encountered in business in
over a decade require a "central" or "master" repository and an official
keeper of the flame. Branches have to be strictly decreed and
controlled, lest anarchy result. If git or Mercurial were used in place
of SVN, the manner in which they'd have to be used would offer zero
benefits over SVN.

I agree that there are plenty of scenarios that benefit from a
distributed VCS. But a whole bunch don't.

Incorrect. Have either of you actually used a DVCS for any length of time
on a team project?

It's true that a great many projects don't need the anarchic
fully-distributed mode of operation that DVCS allows. In fact, the only
one i know of that really uses it is the Linux kernel; even other open
source projects using DVCS have a fairly centralised workflow.

But the thing that DVCS gives you that is invaluable to everyone,
everywhere, is local commits. You can work, commit, work, commit, work,
realise you've gone wrong and roll back to your last commit, work, commit,
work, have an idea, commit, try something experimental, learn something,
roll back to your last commit, work, commit, and so on. All locally,
without having to push up to the server, make a zip file, make a patch, or
do any other monkeying about. All inside the version control system.

It is a massively useful thing to be able to do.

Arved mentioned that "branches have to be strictly decreed and controlled,
lest anarchy result", and that's true, but with one qualification - it's
true of branches *on the server*. People can make whatever branches they
fancy locally, as long as they don't trouble anyone else with them. That
can be useful too, on occasion.

My team moved over to Git a while ago. We have a traditional centralised
workflow: we work locally, and push and pull to a central server. We don't
push and pull to each other. Even for us, a DVCS has been a great tool.

Even if you don't make use of the new powers bestowed on you by a DVCS
(which would be a great mistake), the current crop of DVCSs offer
evolutionary improvements on Subversion. They don't need a server, so
they're easier to set up and manage. They make creating new repositories
much easier. They're faster. They are, incredibly, usually more compact (a
Hg/Git repository + working copy is usually smaller than a Svn working
copy alone - recall that Svn stores a pristine, uncompressed, copy of each
and every file). They don't litter your working copy with millions of
secret directories.

The only downside is that the graphical tools, and integration with other
systems, is not always as good as for Subversion. But note that "not as
good" means "80-90% as good". I use Git and Mercurial through their
Eclipse plugins, and they are basically as good as the Subversion or CVS
plugins. They each have a few warts, but they are purely cosmetic.

So, no, the noise about DVCS is not fashion. It is firmly grounded in
facts.

tom

 

[Andreas Leitgeb]

When you are trying to do archaeology or rollback (say, bisecting to
find a regression range), the "not having atomic commits" suddenly
becomes a major dealbreaker.

This may be true in "worst-case" situations, where the fileset of
each (non-atomic) commit affects large numbers of files, and such
changes happening every few minutes.

I've more often had the need to revert a commit partially (i.e.
only for some of the files), than the non-atomicity causing trouble.
Maybe, this sheds a light on bad practise of the devels (sometimes
committing independent changes in one go), but such is life.

 

[Arved Sandstrom]

On 12/7/2011 1:58 PM, Tom Anderson wrote:
//mindprod.com/jgloss/subversion.html[/url]
http://mindprod.com/jgloss/tortoisesubversion.html

I would say that in this day and age, it is no longer appropriate to
suggest Subversion. Subversion was the best tool available for a
long time, and it is still perfectly serviceable, but there are
better tools available now; projects using it can keep using it
without worry, but there is no reason for a new project, or a
project adopting a new source control system, to start using it.

VCS is an area where fashion often seems to overshadow
facts.

Today with hg and git then SVN is suddenly so oldfashioned - you can
not use a non-distributed VCS without being considered stone age.

The distributed part is great for code that is being worked on by
completely independent organizations (read: large open source projects).

But most people do not really have that need.

I'm with you on this, Arne. You beat me to it actually. 100 percent of
the version control scenarios that I have encountered in business in
over a decade require a "central" or "master" repository and an
official keeper of the flame. Branches have to be strictly decreed and
controlled, lest anarchy result. If git or Mercurial were used in
place of SVN, the manner in which they'd have to be used would offer
zero benefits over SVN.

I agree that there are plenty of scenarios that benefit from a
distributed VCS. But a whole bunch don't.

Incorrect. Have either of you actually used a DVCS for any length of
time on a team project?

In order to acquire facility with Mercurial and Git I use them myself,
on my own work (which may be real work, but doesn't involve anyone
else). I've used Mercurial for about 3 years, have used Git less and
maybe for about 2 years.

I haven't done any open source teamed projects within the past few
years. There have been zero opportunities to use Mercurial or Git on the
job, *with a team*. I have actually tried, three times in as many years,
to make one or the other happen.

It's true that a great many projects don't need the anarchic
fully-distributed mode of operation that DVCS allows. In fact, the only
one i know of that really uses it is the Linux kernel; even other open
source projects using DVCS have a fairly centralised workflow.

But the thing that DVCS gives you that is invaluable to everyone,
everywhere, is local commits. You can work, commit, work, commit, work,
realise you've gone wrong and roll back to your last commit, work,
commit, work, have an idea, commit, try something experimental, learn
something, roll back to your last commit, work, commit, and so on. All
locally, without having to push up to the server, make a zip file, make
a patch, or do any other monkeying about. All inside the version control
system.

It is a massively useful thing to be able to do.

Tom, no need to sell _me_, I am sold already. That's why I have
tried three times in as many years to introduce a DVCS in a real work
environment. Each time it's been a SVN shop (which is part of the
problem, they've already got SVN).

I'll tell you why it's failed:

1. It's (legitimately) hard to convince a client that a centralized DVCS
model is significantly better than a SVN setup. It has to be
_significantly_ better because they are facing a migration of history [1];

2. Very few arguments that have to do with benefits for _developers_ are
important. You don't have to convince developers, you have to convince
managers.

2. Only the developers amongst the client personnel understand your
"local commits" argument, or the other one (better branching/merging
than SVN). Problem is, very few of the managers get it, and _they_ are
the ones that need to be convinced.

I've encountered my share of client managers that actually don't see
your description of local commits as being a good thing, unlike you or
me or most developers. To them that all sounds like coders wasting time
at best, and unsupervised work at worst.

Arved mentioned that "branches have to be strictly decreed and
controlled, lest anarchy result", and that's true, but with one
qualification - it's true of branches *on the server*. People can make
whatever branches they fancy locally, as long as they don't trouble
anyone else with them. That can be useful too, on occasion.

My team moved over to Git a while ago. We have a traditional centralised
workflow: we work locally, and push and pull to a central server. We
don't push and pull to each other. Even for us, a DVCS has been a great
tool.

Even if you don't make use of the new powers bestowed on you by a DVCS
(which would be a great mistake), the current crop of DVCSs offer
evolutionary improvements on Subversion. They don't need a server, so
they're easier to set up and manage. They make creating new repositories
much easier. They're faster. They are, incredibly, usually more compact
(a Hg/Git repository + working copy is usually smaller than a Svn
working copy alone - recall that Svn stores a pristine, uncompressed,
copy of each and every file). They don't litter your working copy with
millions of secret directories.

The only downside is that the graphical tools, and integration with
other systems, is not always as good as for Subversion. But note that
"not as good" means "80-90% as good". I use Git and Mercurial through
their Eclipse plugins, and they are basically as good as the Subversion
or CVS plugins. They each have a few warts, but they are purely cosmetic.

So, no, the noise about DVCS is not fashion. It is firmly grounded in
facts.

tom

Again, _I_ agree with you 100 percent. But Tom, if you read what I
originally wrote, I referred to "business scenarios that I have
encountered", "the manner in which they'd have to be used", and things
of that nature. I wasn't referring to technical superiority of hg or git
over svn, or lack thereof, or vice versa. In fact I'm satisfied that
hg/git are always at least as good as svn, and usually better.

It's simply that I have yet to encounter a team environment where the
managers bought this. I've made three attempts in as many years;
everyone else I've worked with in the past 5 years, say, would have been
as difficult to convince as those three teams.

And bear in mind that quite a few of the arguments in favour of DVCS,
unless pitched very carefully (and sometimes de-emphasized), either
don't interest managers, or they don't like what they hear. I've also
encountered a couple of organizational version control types who have to
be carefully talked to so they don't feel threatened by "developer
empowerment", and once you've semi-successfully done that then they
don't care enough about DVCS to be champions either.

Let me put it this way, and maybe this helps to make my point: "they
make creating new repositories much easier", as you mentioned above, is
_not_ a selling point in many client environments. There is zero appeal
to many managers of developers being able to make repositories, and
there can be substantial pushback to features like this. To many
managers the features of DVCSs that you or I (or other with-it
developers) like are negative selling points, because they interpret
those as leading to lack of control and lack of visibility.

Sooner or later I'll succeed in getting a client organization
interested, and interested for the right reasons. But it hasn't happened
yet.

AHS

1. History is super-important in these organizations. It is how you
locate scapegoats.

 

[Andreas Leitgeb]

Let me put it this way, and maybe this helps to make my point: "they
make creating new repositories much easier", as you mentioned above, is
_not_ a selling point in many client environments. There is zero appeal
to many managers of developers being able to make repositories, and
there can be substantial pushback to features like this. To many
managers the features of DVCSs that you or I (or other with-it
developers) like are negative selling points, because they interpret
those as leading to lack of control and lack of visibility.

I'm putting in a word for the managers:

The longer you keep your changes local (even if "locally commited"), the
higher is the risk of a conflict with other devels' changesets.

I can imagine managers to be more afraid of longer sync-intervals,
resulting from the DVCS-philosophy, than of not seeing all devels'
interims work.

Sooner or later I'll succeed in getting a client organization
interested, and interested for the right reasons. But it hasn't
happened yet.

It would have to be a client whose devels are working remote, and
where the benefits of piling up some work before a sync outweighs
the higher risk of conflicts happening.

1. History is super-important in these organizations. It is how you
locate scapegoats.

I do understand this motivation. The "scapegoat" is typically the one
who is in the best position to fix a problem, so identifying him without
having to ask everyone is worth as much time as by what the scapegoat
will be able to fix it more efficiently than anyone else on the project.

 

[Lars Enderin]

I'm putting in a word for the managers:

The longer you keep your changes local (even if "locally commited"), the
higher is the risk of a conflict with other devels' changesets.

Have you thought about how "devel" sounds to a native English speaker? I
wouldn't use that abbrev.