Bazaar and Java IDEs (was Bazaar and Visual Studio)

[Talden]

On Wed, Sep 15, 2010 at 8:40 PM, Philippe Lhoste <PhiLho at gmx.net> wrote:
> On 15/09/2010 03:20, Max Bowsher wrote:
>>
>> I personally am quite a light user of IDE integration (I habitually
>> commit from the command line).
>
> Me too.
> At work, we use Eclipse and have Perforce as VCS.
> Historically, I used the Perforce (P4) GUI, which was quite good and
> improved quickly (using Qt too).
> Some colleagues (mostly those having a Linux box) just prefer to use the
> command line...
>
> Finally, I installed the Perforce plugin for Eclipse.
> But at the end, I often fall back on the GUI... I just use the plugin so it
> checks out the files for me when I start to edit them (P4 makes the
> versioned files read-only and makes them writable when they are checked
> out).
> To see the currently checked out files, the history of changelists, make
> diffs, submit the changelists and so on, I just use the native GUI.
>
> It is the same with Bazaar, and even if I appreciate Bzr-explorer, I find
> myself using mostly the command line to have status, add files, commit, etc.

Our situation is:
* Java development shop working on Windows using a mix of Eclipse and
IntelliJ IDEA.
* We're miles from the server, looooong ping-times mean subversion is
quite painful (better than CVS though).
* Our checkouts have a great many tiny files and many many folders
(java package trees). Many folders make Subversion very very slow
(.svn folders in each) and also make commandline use cumbersome.
* Developers generally use TortoiseSVN for checkout, update, status,
commit, branching and tagging.
* Developers use IDE integration for refactoring (rename/move), log,
diff and conflict resolution.
* Merging is usually done by postponing conflict resolution and then
dealing with it either the IDE or Beyond Compare depending on the
developer (most use beyond compare as it does decent 3-way merge along
with syntax highlighting).

Our developers are accustomed to waiting as 20s+ for a status, 1m+ for
an update (heck it's nearly a minute for a no-op update with
warm-cache).  Subversion is painful for so many yet they would rather
this inefficiency than give up their IDE + Shell integration.

NB: Most of Subversions slowness can be attributed to the
locking/unlocking of the working copy (many many folders) and the very
long reound-trips to the server.  Bazaar solves both of these and with
a shared repository also dramatically reduces the 'checkout' sizes
since it means one copy of pristine file-content.  Subversion 1.7 will
alleviate some of this and 1.8 even more but the server round-trip
problem is simply a centralised VCS problem.

I think there are only two of us now who do most of our VCS work via
the commandline (yet often the commandline is faster because you can
focus the VCS effort more precisely). I even have a local repo mirror
simply because it's often quicker to 'switch --relocate' to the mirror
for multiple read ops and switch back for the commit - merge is
sloooooooow.

Subversions lack of easier merging means a lot of small commits to
trunk rather than branching and merging.  This brings its own kinds of
pain...

I use bazaar exclusively at home but don't expect to get acceptance at
my work-place (or expect to see significant bazaar integration
progress anytime soon - there are simply too many more important
things to do in bazaar).

It's good to see this being discussed though as I do think it's a
significant barrier to getting wider bazaar adoption.

--
Talden