should we use bazaar?

[Jim White]

Russel Winder wrote:

> On Thu, 2008-06-26 at 20:02 +0700, Chanwit Kaewkasi wrote:
>
>
>>Russel mentioned somethings not good about bazaar-SVN interop in this
>>list as well.
>>I've faced that problem, so I decided to try Git.
>
>
> An update on this.  Although not yet in production form, Jelmer has
> added the dpush command to Bazaar, so that Bazaar can now be used in the
> same way that Git interacts with Subversion -- 'bzr dpush' behaves in a
> directly analogous manner to 'git svn dcommit'.  This means that not
> only can Bazaar store a Bazaar branch in a Subversion repository, it can
> act as a DVCS client for a Subversion repository master branch.  Git
> only supports the latter, and Mercurial doesn't support interworking at
> all (to my knowledge).
> ...

 From my post in this thread last week:

One of the interesting syncing tools is hgsvn which lets you use Hg on
SVN checkouts.  That solves your disconnected operation case and allows
a thorough evaluation of Hg before making the switch for the central
repository.

That of course is one the essential virtues of distributed version
control.  And naturally even more useful in the future will be
cross-DVCS synchronization so that this issure will become moot.

http://cheeseshop.python.org/pypi/hgsvn

Jim


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Jim White schrieb:
[...]

>  From my post in this thread last week:
>
> One of the interesting syncing tools is hgsvn which lets you use Hg on
> SVN checkouts.  That solves your disconnected operation case and allows
> a thorough evaluation of Hg before making the switch for the central
> repository.
>
> That of course is one the essential virtues of distributed version
> control.  And naturally even more useful in the future will be
> cross-DVCS synchronization so that this issure will become moot.
>
> http://cheeseshop.python.org/pypi/hgsvn

it is possible with all thre of them I think... but I personally think,
that because Bazaar has an API and git is "only" a commandline tool,
that bazaar is better than git.. don't know about Mecurial.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jim White]

Jochen Theodorou wrote:

> Jim White schrieb:
> [...]
>
>>  From my post in this thread last week:
>>
>> One of the interesting syncing tools is hgsvn which lets you use Hg on
>> SVN checkouts.  That solves your disconnected operation case and
>> allows a thorough evaluation of Hg before making the switch for the
>> central repository.
>>
>> That of course is one the essential virtues of distributed version
>> control.  And naturally even more useful in the future will be
>> cross-DVCS synchronization so that this issure will become moot.
>>
>> http://cheeseshop.python.org/pypi/hgsvn
>
> it is possible with all thre of them I think... but I personally think,
> that because Bazaar has an API and git is "only" a commandline tool,
> that bazaar is better than git.. don't know about Mecurial.

I think Mercurial is probably better than Bazaar.

A repost of what I said last week:

Jochen Theodorou wrote:

 > ...
 > (3) can explain why another tool is better

I haven't done a direct comparison myself, but my impression so far is
that Mercurial is probably a better choice than Bazaar.

If you consider that projects like OpenJDK, IcedTea, NetBeans, and
OpenSolaris have found it the current best choice for distributed
version control, then I'm sure you'd agree that at this point
alternatives would need to explain why they're better.

http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial

There is SVN-to-Hg conversion available, as well as SVN-and-Hg sync.

http://www.selenic.com/mercurial/wiki/index.cgi/RepositoryConversion

One of the interesting syncing tools is hgsvn which lets you use Hg on
SVN checkouts.  That solves your disconnected operation case and allows
a thorough evaluation of Hg before making the switch for the central
repository.

That of course is one the essential virtues of distributed version
control.  And naturally even more useful in the future will be
cross-DVCS synchronization so that this issure will become moot.

http://cheeseshop.python.org/pypi/hgsvn

Some DVCS comparison articles:

http://www.dribin.org/dave/blog/archives/2007/12/28/dvcs/

http://www.opensolaris.org/os/community/tools/scm/

"Why Java picked Mercurial for source control" interview with Gosling:
http://www.builderau.com.au/video/play/22447748

http://bazaar-vcs.org/BzrVsHg

http://www.selenic.com/mercurial/wiki/index.cgi/BzrVsHg

http://www.selenic.com/mercurial/wiki/index.cgi/Bazaar

My best current thought it is too early for a project like Groovy to be
concerned about switching to DVCS.  Developers who want to use DVCS
should use SVN-and-DVCS-of-personal-choice-synchronization over the next
year or so.  Then the tools will then be more mature and the value of
switching (if any) will be clear.

Jim


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Alexander Veit-5]

> From: Jochen Theodorou wrote:
> Well, Git might be faster.. but how much? If there is not a
> bazaar operation that takes 10 minutes with it but only 1
> with git, then there is probably not much to talk about. Or
> are there operations with different complexitiy?

Git ist faster (http://www.infoq.com/articles/dvcs-guide) but it's client
support (especially Windows clients) seems to be less mature than Bazaar's
or Mercurial's.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Jim White schrieb:

> Jochen Theodorou wrote:
>
>> Jim White schrieb:
>> [...]
>>
>>>  From my post in this thread last week:
>>>
>>> One of the interesting syncing tools is hgsvn which lets you use Hg
>>> on SVN checkouts.  That solves your disconnected operation case and
>>> allows a thorough evaluation of Hg before making the switch for the
>>> central repository.
>>>
>>> That of course is one the essential virtues of distributed version
>>> control.  And naturally even more useful in the future will be
>>> cross-DVCS synchronization so that this issure will become moot.
>>>
>>> http://cheeseshop.python.org/pypi/hgsvn
>>
>> it is possible with all thre of them I think... but I personally
>> think, that because Bazaar has an API and git is "only" a commandline
>> tool, that bazaar is better than git.. don't know about Mecurial.
>
> I think Mercurial is probably better than Bazaar.
>
> A repost of what I said last week:
>
> Jochen Theodorou wrote:
>
>  > ...
>  > (3) can explain why another tool is better
>
> I haven't done a direct comparison myself, but my impression so far is
> that Mercurial is probably a better choice than Bazaar.
>
> If you consider that projects like OpenJDK, IcedTea, NetBeans, and
> OpenSolaris have found it the current best choice for distributed
> version control, then I'm sure you'd agree that at this point
> alternatives would need to explain why they're better.

I don't count that as argument. I would need to know why these projects
chose Mercurial over Bazaar and if these reasons are still valid. On
http://www.dribin.org/dave/blog/archives/2007/12/28/dvcs/ you can find:

"""
> Historically, the main complaint about Bazaar has been it’s
> performance. In fact, the main reason why OpenSolaris dismissed
> Bazaar was due to poor performance. But that eval was a year ago,
> which is essentially an eternity. Since then, Bazaar has hit 1.0 and
> those performance criticisms have supposedly been addressed.
"""

so I read performance was the main reason, and that one is not that
valid anymore. ..
http://opensolaris.org/os/community/tools/scm/bzr-eval/ suggests the same.

[...]
> "Why Java picked Mercurial for source control" interview with Gosling:
> http://www.builderau.com.au/video/play/22447748

that should be named "Why Java picked a DCVS". Afaik they don't compare
Mercurial, GIT and Bazaar

  bye blackdrag


--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Alexander Veit schrieb:
>> From: Jochen Theodorou wrote:
>> Well, Git might be faster.. but how much? If there is not a
>> bazaar operation that takes 10 minutes with it but only 1
>> with git, then there is probably not much to talk about. Or
>> are there operations with different complexitiy?
>
> Git ist faster (http://www.infoq.com/articles/dvcs-guide) but it's client
> support (especially Windows clients) seems to be less mature than Bazaar's
> or Mercurial's.

yes, looks like it...

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[chanwit]

My experiences of Git on Windows via Cygwin have been good so far.

Cheers,

Chanwit

2008/7/1 Alexander Veit <alexander.veit@...>:

>> From: Jochen Theodorou wrote:
>> Well, Git might be faster.. but how much? If there is not a
>> bazaar operation that takes 10 minutes with it but only 1
>> with git, then there is probably not much to talk about. Or
>> are there operations with different complexitiy?
>
> Git ist faster (http://www.infoq.com/articles/dvcs-guide) but it's client
> support (especially Windows clients) seems to be less mature than Bazaar's
> or Mercurial's.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jim White]

Jochen Theodorou wrote:

> Jim White schrieb:
...

>> Jochen Theodorou wrote:
>>
>>  > ...
>>  > (3) can explain why another tool is better
>>
>> I haven't done a direct comparison myself, but my impression so far is
>> that Mercurial is probably a better choice than Bazaar.
>>
>> If you consider that projects like OpenJDK, IcedTea, NetBeans, and
>> OpenSolaris have found it the current best choice for distributed
>> version control, then I'm sure you'd agree that at this point
>> alternatives would need to explain why they're better.
>
>
> I don't count that as argument. I would need to know why these projects
> chose Mercurial over Bazaar and if these reasons are still valid. On
> http://www.dribin.org/dave/blog/archives/2007/12/28/dvcs/ you can find:
>
> """
>> Historically, the main complaint about Bazaar has been it’s
>> performance. In fact, the main reason why OpenSolaris dismissed
>> Bazaar was due to poor performance. But that eval was a year ago,
>> which is essentially an eternity. Since then, Bazaar has hit 1.0 and
>> those performance criticisms have supposedly been addressed.
> """
>
> so I read performance was the main reason, and that one is not that
> valid anymore. ..
> http://opensolaris.org/os/community/tools/scm/bzr-eval/ suggests the same.

The idea that one software project that was X months behind another
active, successful project has somehow eliminated a feature and/or
performance gap is naive.   You would have to suppose that Mercurial
stood still while Bazaar addresses its most serious deficiency in the
comparison.

So as I say, given that Bazaar was convincingly inferior to Mercurial a
year ago, it now must prove it is either equivalent or superior now in
order to regard it is equal or superior.

And you omitted what I consider my most relevant opinion in this
discussion, which is that it is far too early for the Groovy project to
seriously consider switching off of Subversion.

Not only are the DVCS client tools immature, what about the server-side?
  Besides the inevitable discovery of data reliability issues, there are
the web UI and issue tracking integration functions that have to be
dealt with too.

Maybe in a year (but more likely longer), the DVCS tools will be worth
switching to.  Moreover, folks who really do want to adapt to DVCS from
Subversion will be integrating the synchronization tools on the
server-side in order to preserve their Subversion repository (for it's
dependability and integration with other services) while satisfying the
clamor for DVCS.

Jim


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Mark Derricutt]

If one went mercurial theres a nice-ish mercurial plugin for IntelliJ (thou I've not seen any new releases lately).  It's in the plugin manager.

Mark

On Fri, Jun 27, 2008 at 12:38 AM, Alex Tkachman <alex.tkachman@...> wrote:

Is it possible to setup bazaar in a way that for me it will be
subversion? I heard somewhere that it is possible.
I have so nice integration in IntelliJ

--
"It is easier to optimize correct code than to correct optimized code." -- Bill Harlan

[Russel Winder-4]

On Mon, 2008-06-30 at 12:52 -0700, Jim White wrote:

> I think Mercurial is probably better than Bazaar.

I suspect we are, in the main, going to be arguing personal preference.
Almost all the debate about Bazaar, Mercurial and Git revolves around
performance and personal preferences for the  branching model and the
command set.  Bazaar and Mercurial have improved their performance
markedly over the last year, so all the performance data from over a
year ago is no longer valid.  If performance is to be a driver then new
data will be required.

> I haven't done a direct comparison myself, but my impression so far is
> that Mercurial is probably a better choice than Bazaar.

See above :-)

> If you consider that projects like OpenJDK, IcedTea, NetBeans, and
> OpenSolaris have found it the current best choice for distributed
> version control, then I'm sure you'd agree that at this point
> alternatives would need to explain why they're better.

MySQL has chosen Bazaar.  Also of course Bazaar is officially a GNU
project -- though this might make some people turn against it for
political reasons!

> There is SVN-to-Hg conversion available, as well as SVN-and-Hg sync.
>
> http://www.selenic.com/mercurial/wiki/index.cgi/RepositoryConversion
>
> One of the interesting syncing tools is hgsvn which lets you use Hg on
> SVN checkouts.  That solves your disconnected operation case and allows
> a thorough evaluation of Hg before making the switch for the central
> repository.

I haven't tried this as yet, I must do so.  The trouble with having the
functionality you need in the tool you already use is that it means a
positive effort is needed to try a different tool.

> My best current thought it is too early for a project like Groovy to be
> concerned about switching to DVCS.  Developers who want to use DVCS
> should use SVN-and-DVCS-of-personal-choice-synchronization over the next
> year or so.  Then the tools will then be more mature and the value of
> switching (if any) will be clear.

Yes and no.  Personally, I would prefer to switch to a DVCS sooner
rather than later, Bazzar for preference but Mercurial or even Git if
that was the majority decision -- actually at the end of the day this is
where Guillaume gets to exercise despotishness, he has the final choice!

The single biggest factor here is "What do Codehaus support?"  I do not
see that there is any need or desire to change hosting from Codehaus to,
say, Launchpad.  Currently Codehaus supports only Subversion.  They are
however looking at Bazaar, Mercurial and Git.  Personally I am not
convinced Git is an option for Windows users not using Cygwin, but by
the time Codehaus have their support for DVCS in place this may have
changed.

I think the issues are definitely tool support for the tools that people
actually need on the platforms people actually use. I think in terms of
operating systems this means Windows, Mac OS X, Ubuntu, Red Hat,
Solaris.  I agree that as of today the GUI tools, and to some extent the
IDE plugins for DVCS support are less mature that the ones for
Subversion.  But again by the time Codehaus have support for DVCS this
will have changed.  Actually I am using the Eclipse Bazaar support all
the time and it works fine.  I suspect the Mercurial and Git support is
equally good.

Of course there is no difficulty for individuals to use Bazaar,
Mercurial or Git as their client to Subversion immediately.  Certainly
this is what I am doing.  Now that Bazaar has the dpush command, I think
people will find it difficult to know from the commit logs whether I
have used Bazaar, Git, or even Subversion to make the commit.  Of course
this only works where a branch is an individual thing, where
collaboration is required more coordination is needed.

Summary:  Until Codehaus officially support a DVCS, all discussion of
the main branch moving to a DVCS are moot.  It is good to discuss so we
know what the issues are, but a decision is moot.  Until then there is
no problem using whatever client people want to use to work with the
Subversion repository.  Only if two people need to collaborate on a
branch is there any issue at all about making a choice of client.  I
would always choose Bazaar, but others may have different views.

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: [phone], [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]

[Russel Winder-4]

On Mon, 2008-06-30 at 21:19 +0200, Jochen Theodorou wrote:

> Can I take this as that I can simply use bazaar locally, without
> changing svn and then commit to svn, whenever I like to do so and
> without somebody seeing I actually did it using bazaar? I mean if it is
> like this, then we could for now switch to wahtever can work with the
> subversion backend unmodified and let the individual developer decide
> what to take. We could then still switch to another repository system later

You can do this with either Bazaar or Git.  From what Jim says you can
do this with Mercurial as well -- I will check this out later in the
week.

Because I prefer Bazaar over Git, I have created Bazaar branches for
Groovy and Gant and am maintaining them on Launchpad.  This is actually
more of a Groovy and Gant marketing exercise than anything else.  But
what it does mean is that people have a branch they can go to to start
using Bazaar as their Subversion client without the hassle of having to
wait a long time for the generation of their own branch direct out of
Subversion.

Perhaps there is also an argument for hosting the Git repository
somewhere as well.

The dpush command for Bazaar is only available in the bzr-svn 0.4.11
beta using bzr 1.6 beta, but both should be released very soon now.
Using push to a Subversion repository means the metadata for the Bazaar
branch is added to the Subversion repository, dpush does not do this.
If the Codehaus Subversion commit hook didn't list all property changes
then there wouldn't be an issue but Ben doesn't have the time to
investigate switching from using svnlook to using the Python mail hook.
I use the Python mail hook for my Subversion repositories and so I don't
see the problem that I mention previously and caused Chanwit to switch
to Git as his Subversion client.  The dpush command makes all the
Codehaus commit hook hassle go away in the same way the using git svn
dcommit does.

> > Yes, Git is still a little faster (well quite a lot is some cases), but
> > Bazaar is so much easier to use.
>
> Well, Git might be faster.. but how much? If there is not a bazaar
> operation that takes 10 minutes with it but only 1 with git, then there
> is probably not much to talk about. Or are there operations with
> different complexitiy?

It depends on the command.  For basic commit, diff, etc. Git is faster
than Bazaar but you wouldn't worry about it as they are both fast
enough.  For some log operation Git is very much faster than Bazaar and
so you would care.  For some push and pull operations, Git can be a lot
faster than Bazaar, but in the main they are both fast enough not to
care about the difference.  I suspect Mercurial sits between Git and
Bazaar in all cases.

For me the issues are that the speed issues are not generally an issue,
i.e. the extra speed of Git does not offset my preference for the branch
model of Bazaar compared to Git, and the command line command set.  And
I much prefer olive-gtk (the GTK bazaar GUI) to the Git equivalents.
Except there is one thing about gitk that is really cool, and I have a
feature request in to have that added to the equivalent Bazaar tool.

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: [phone], [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]

[Russel Winder-4]

On Mon, 2008-06-30 at 21:56 -0700, Jim White wrote:

> The idea that one software project that was X months behind another
> active, successful project has somehow eliminated a feature and/or
> performance gap is naive.   You would have to suppose that Mercurial
> stood still while Bazaar addresses its most serious deficiency in the
> comparison.
>
> So as I say, given that Bazaar was convincingly inferior to Mercurial a
> year ago, it now must prove it is either equivalent or superior now in
> order to regard it is equal or superior.

The main factor here is the change of repository format in Bazaar.  As
the Mercurial people keep saying "Bazaar keeps changing the repository
format because they can't decide what to do".  What has happened of
course is that Bazaar is now using the same format as Git for speed.
The speed change with the Bazaar format change was pretty immense, and
they are still working on it.

So I would say all the performance differentials between Bazaar,
Mercurial and Git have changed.

> And you omitted what I consider my most relevant opinion in this
> discussion, which is that it is far too early for the Groovy project to
> seriously consider switching off of Subversion.
>
> Not only are the DVCS client tools immature, what about the server-side?
>   Besides the inevitable discovery of data reliability issues, there are
> the web UI and issue tracking integration functions that have to be
> dealt with too.

I think you are being over-conservative here.  If Sun, MySQL, Mozilla,
etc. can switch to a DVCS then there is no fundamental barrier stopping
Groovy.  Except one, Codehaus.  Your server-side point is critical here.
No Codehaus support means no change from Subversion for the central
master branch.  This doesn't stop individuals choosing better clients to
work with that central master branch.

> Maybe in a year (but more likely longer), the DVCS tools will be worth
> switching to.  Moreover, folks who really do want to adapt to DVCS from
> Subversion will be integrating the synchronization tools on the
> server-side in order to preserve their Subversion repository (for it's
> dependability and integration with other services) while satisfying the
> clamor for DVCS.

I hope your forecast is too conservative.  Clearly a project cannot chop
and change infrastructureregualrly, so there must be no hasty decisions.
But it is good to have a roadmap.  This implies the sort of debate we
have been having.

In the end though for Groovy and Gant, it all depends on what Codehaus
do.  Until they have decided which DVCS to support all decision making
about switching to a DVCS is moot.   If they end up providing Bazaar,
Mercurial and Git, then we have a decision to make.

Subversion is a fine version filestore but compared to a DVCS it is
fundamentally inadequate for software development except where you have
one and only one branch and never need another branch.  This includes
Subversion 1.5.  If Groovy, Gant etc. never need more than one branch
then there is no need to even contemplate a move from Subversion.
However, I think that is not the case.  The "clamour for DVCS" is based
on a real workflow and function factors.
--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: [phone], [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]

[Jochen Theodorou]

Jim White schrieb:
> Jochen Theodorou wrote:
[...]
> Maybe in a year (but more likely longer), the DVCS tools will be worth
> switching to.  Moreover, folks who really do want to adapt to DVCS from
> Subversion will be integrating the synchronization tools on the
> server-side in order to preserve their Subversion repository (for it's
> dependability and integration with other services) while satisfying the
> clamor for DVCS.

I think it is now the right time to decide on a tool, even if we switch
to it much later. The reason is that there must be infrastructure on
codehaus. If we are sure we want DCVS, then we should decide which of th
systems, so the codehaus people can concentrate on the ones the projects
do request. Most likely they will do only one of them. So the bestwould
be to make a top3, which seems to be for me Mercurial, Bazaar, Git at
the moment, meaning that I prefer Mercurial and Bazaar over Git. As of
the format on the server side... that is not really our problem, that is
the problem of the guys on the server, and they are surely will take an
eye on it. I think for us the most important things are not memory and
speed, but tool support and support for the workflow we target.

I placed Mercurial at 1, because it seems TortoiseBzr is no longer
developed, but TortoiseHg still is. There are basic plugins for all
IDEs, including Intellij, Eclipse and Netbeans. Mercurial and Bazaar
work on all operating systems, because they are not written in a wild
mix of C,bash, Perl and TCL/Tk. I dislike git mostly because of its huge
ammount of command line arguments. In subversion you had what? checkout,
commit, update, diff... maybe merge and copy. That's it. Do we really
need more than that?

I am usually having different directories for groovy, where each
directory represents a certain branch. That menas atm I have a 1.5.x
directory and a 1.6.x directory. If I take it right, then for git you
have the whole repository in the top level directory, but the classic
checkout is made only on a certain branch... meaning I would either have
to symlink the .git directories or have two of them.... But having two
of them... The initial checkout takes really a long time. Now, that
might bea problem for all three systems...I would have to find a way to
checkout not the whole thing, but only a certain part... in some cases
this is just what I need.. and I don't wnat to waste several 100MB just
to get 20of them in the end.

Which leeds me to the workflow itself... How should that be? I know git
supports almost any workflow, but what kind of workflow do bazaar and
Mercurial support? I mean if none of them allows the workflow we want to
have, then there is no reason to use them. But frankly I don't know
about the workflow yet. I am only sure that having one main maintainer
that has the only power of hte branch is most likely not going to work
for us.... also I never understood how I can pull a different version
from someone, if that someone doesn't host the version...

Even if we switch to a DCVS System, we most likely will still have a
central repository in the end... or were are the other repositories
comming from?

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

Jochen,

On Tue, 2008-07-01 at 13:05 +0200, Jochen Theodorou wrote:

> I think it is now the right time to decide on a tool, even if we switch
> to it much later. The reason is that there must be infrastructure on
> codehaus. If we are sure we want DCVS, then we should decide which of th
> systems, so the codehaus people can concentrate on the ones the projects
> do request. Most likely they will do only one of them. So the bestwould
> be to make a top3, which seems to be for me Mercurial, Bazaar, Git at
> the moment, meaning that I prefer Mercurial and Bazaar over Git. As of
> the format on the server side... that is not really our problem, that is
> the problem of the guys on the server, and they are surely will take an
> eye on it. I think for us the most important things are not memory and
> speed, but tool support and support for the workflow we target.

I think this is a good point.  Codehaus are reactive as well as
proactive.  They have set up Xircles so they can deal with DVCS as well
as Subversion, and are looking at which DVCS to offer.  If we can say we
want to use X where X in {Bazaar, Mercurial, Git} that will help them.
 
> I placed Mercurial at 1, because it seems TortoiseBzr is no longer
> developed, but TortoiseHg still is. There are basic plugins for all
> IDEs, including Intellij, Eclipse and Netbeans. Mercurial and Bazaar
> work on all operating systems, because they are not written in a wild
> mix of C,bash, Perl and TCL/Tk. I dislike git mostly because of its huge
> ammount of command line arguments. In subversion you had what? checkout,
> commit, update, diff... maybe merge and copy. That's it. Do we really
> need more than that?

This statement about TortoiseBzr is not correct. Canonical spotted that
development was stalled and have engaged Mark Hammond to pick things up
and carry it to release, so there is paid help on the job now.  There is
a release early, release often programme in place.

As will be pretty obvious from my previous emails, my preferred ordering
would be Bazaar, Mercurial, Subversion, Git.

> I am usually having different directories for groovy, where each
> directory represents a certain branch. That menas atm I have a 1.5.x
> directory and a 1.6.x directory. If I take it right, then for git you
> have the whole repository in the top level directory, but the classic
> checkout is made only on a certain branch... meaning I would either have
> to symlink the .git directories or have two of them.... But having two
> of them... The initial checkout takes really a long time. Now, that
> might bea problem for all three systems...I would have to find a way to
> checkout not the whole thing, but only a certain part... in some cases
> this is just what I need.. and I don't wnat to waste several 100MB just
> to get 20of them in the end.

In Bazaar you would have a shared repository with the Trunk, 1.6.x and
1.5.x branches in it.  They then share changesets.  In Git you have a
repository in which all the branches reside with sharing of all
changesets.  What the best with Mercurial I am not sure just now.

> Which leeds me to the workflow itself... How should that be? I know git
> supports almost any workflow, but what kind of workflow do bazaar and
> Mercurial support? I mean if none of them allows the workflow we want to
> have, then there is no reason to use them. But frankly I don't know
> about the workflow yet. I am only sure that having one main maintainer
> that has the only power of hte branch is most likely not going to work
> for us.... also I never understood how I can pull a different version
> from someone, if that someone doesn't host the version...

Git supports the "Linus managing Linux development" workflow.  OK so it
can be coerced to others.  Bazaar and Mercurial are designed to be much
more agile and adaptive.  Bazaar can in fact cover more different
workflows than Git, as I think Mercurial can.

I think the trick here is to specify the workflow you want and then fit
the tool to the job, and in the process see if one of the tools rules
itself out.  I suspect that this is not the case, that all three can be
used with any of the workflows we want to put in place.

Associated with Bazaar is Bundle Buggy and Patch Queue Manager, these
are ways of formalizing the acceptence of changesets into the mainline
branch. They are lightweight, developed by the Bazaar developers to
support Bazaar development.  I am sure Mercurial and Git have analogues.

With any system there will always be one branch that is accepted as
being the mainline (trunk in Subversion speak).  The question is how to
manage updates to that mainline.  Part of this is access control, part
of this is changeset management.  The Bazaar, Mercurial and Git
developers will create tools for their own use so rather than start from
scratch and try and work things out from first principles, it is
probably best just to pick up what they have.

> Even if we switch to a DCVS System, we most likely will still have a
> central repository in the end... or were are the other repositories
> comming from?

Anyone can have a branch, that is the whole point of DVCS.  But there
will always be one that the community accept as being the official state
of software.

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: [phone], [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Russel Winder schrieb:
[...]

>> I placed Mercurial at 1, because it seems TortoiseBzr is no longer
>> developed, but TortoiseHg still is. There are basic plugins for all
>> IDEs, including Intellij, Eclipse and Netbeans. Mercurial and Bazaar
>> work on all operating systems, because they are not written in a wild
>> mix of C,bash, Perl and TCL/Tk. I dislike git mostly because of its huge
>> ammount of command line arguments. In subversion you had what? checkout,
>> commit, update, diff... maybe merge and copy. That's it. Do we really
>> need more than that?
>
> This statement about TortoiseBzr is not correct.

oh?

> Canonical spotted that
> development was stalled and have engaged Mark Hammond to pick things up
> and carry it to release, so there is paid help on the job now.  There is
> a release early, release often programme in place.

but it seems there are still no committs

> As will be pretty obvious from my previous emails, my preferred ordering
> would be Bazaar, Mercurial, Subversion, Git.

I played a little with git... and was not very pleased about its
complexity... I had to spend over an hour to find out how to checkout a
certain release that is not head. I will try Bazaar and Mercurial soon

>> I am usually having different directories for groovy, where each
>> directory represents a certain branch. That menas atm I have a 1.5.x
>> directory and a 1.6.x directory. If I take it right, then for git you
>> have the whole repository in the top level directory, but the classic
>> checkout is made only on a certain branch... meaning I would either have
>> to symlink the .git directories or have two of them.... But having two
>> of them... The initial checkout takes really a long time. Now, that
>> might bea problem for all three systems...I would have to find a way to
>> checkout not the whole thing, but only a certain part... in some cases
>> this is just what I need.. and I don't wnat to waste several 100MB just
>> to get 20of them in the end.
>
> In Bazaar you would have a shared repository with the Trunk, 1.6.x and
> 1.5.x branches in it.  They then share changesets.  In Git you have a
> repository in which all the branches reside with sharing of all
> changesets.  What the best with Mercurial I am not sure just now.

I guess I simply have to try it.

>> Which leeds me to the workflow itself... How should that be? I know git
>> supports almost any workflow, but what kind of workflow do bazaar and
>> Mercurial support? I mean if none of them allows the workflow we want to
>> have, then there is no reason to use them. But frankly I don't know
>> about the workflow yet. I am only sure that having one main maintainer
>> that has the only power of hte branch is most likely not going to work
>> for us.... also I never understood how I can pull a different version
>> from someone, if that someone doesn't host the version...
>
> Git supports the "Linus managing Linux development" workflow.  OK so it
> can be coerced to others.  Bazaar and Mercurial are designed to be much
> more agile and adaptive.  Bazaar can in fact cover more different
> workflows than Git, as I think Mercurial can.

oh, well I got it false then? But now that you say it, I remember that too.

> I think the trick here is to specify the workflow you want and then fit
> the tool to the job, and in the process see if one of the tools rules
> itself out.  I suspect that this is not the case, that all three can be
> used with any of the workflows we want to put in place.
>
> Associated with Bazaar is Bundle Buggy and Patch Queue Manager, these
> are ways of formalizing the acceptence of changesets into the mainline
> branch. They are lightweight, developed by the Bazaar developers to
> support Bazaar development.  I am sure Mercurial and Git have analogues.

probably, didn't find anything.

[...]
>> Even if we switch to a DCVS System, we most likely will still have a
>> central repository in the end... or were are the other repositories
>> comming from?
>
> Anyone can have a branch, that is the whole point of DVCS.  But there
> will always be one that the community accept as being the official state
> of software.

well, yes, sure... ut where are these branches physically? I more or
less came to this problem when hearing the google talk from Linus to
advocate GIT. He is pulling from others.. If I understand this right,
then there is some kind of remote repository and he is getting the
actual version from it. If not, then it would be a simple patch send by
for example email, or not? Bazaar seems not to work like this... at
least with the tools from above. It seems that then you have the patches
send to the mailing list and an automated tool will merge them. So there
is no need to access a remote repository. Am I worng about this?

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

Jochen,

On Tue, 2008-07-01 at 14:40 +0200, Jochen Theodorou wrote:
> Russel Winder schrieb:
> [...]
> >> I placed Mercurial at 1, because it seems TortoiseBzr is no longer
> >> developed, but TortoiseHg still is. There are basic plugins for all
[ . . . ]

> > This statement about TortoiseBzr is not correct.
>
> oh?
>
> > Canonical spotted that
> > development was stalled and have engaged Mark Hammond to pick things up
> > and carry it to release, so there is paid help on the job now.  There is
> > a release early, release often programme in place.
>
> but it seems there are still no committs

https://code.launchpad.net/~tortoisebzr-developers/tortoisebzr/tbzr2-proto

Looks active to me.

> > As will be pretty obvious from my previous emails, my preferred ordering
> > would be Bazaar, Mercurial, Subversion, Git.
>
> I played a little with git... and was not very pleased about its
> complexity... I had to spend over an hour to find out how to checkout a
> certain release that is not head. I will try Bazaar and Mercurial soon

Reverting a file is the one that gets me thinking there is something
wrong with the command line structure.  Not to mention that the checkout
command is overloaded and sometimes changes branch and sometimes
doesn't.

[ . . . ]

> > Anyone can have a branch, that is the whole point of DVCS.  But there
> > will always be one that the community accept as being the official state
> > of software.
>
> well, yes, sure... ut where are these branches physically? I more or
> less came to this problem when hearing the google talk from Linus to
> advocate GIT. He is pulling from others.. If I understand this right,
> then there is some kind of remote repository and he is getting the
> actual version from it. If not, then it would be a simple patch send by
> for example email, or not? Bazaar seems not to work like this... at
> least with the tools from above. It seems that then you have the patches
> send to the mailing list and an automated tool will merge them. So there
> is no need to access a remote repository. Am I worng about this?

Branches can be anywhere.  Usually though they are accessible either
over SSH or HTTP(S).  So for strictly controlled access branches you use
the SSH access, HTTP gives public read-only access, and HTTPS+WebvDAV
gives you controlled writeable access.

Launchpad (for Bazaar), GitHub (for Git), Savannah (Bazaar, Mercurial or
Git) all provide branch/repository hosting.  Hopefully soon so will
Codehaus.

Doing things with email and patch queues is another way instead of
accessing .
--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: [phone], [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]

[Jochen Theodorou]

Russel Winder schrieb:

> Jochen,
>
> On Tue, 2008-07-01 at 14:40 +0200, Jochen Theodorou wrote:
>> Russel Winder schrieb:
>> [...]
>>>> I placed Mercurial at 1, because it seems TortoiseBzr is no longer
>>>> developed, but TortoiseHg still is. There are basic plugins for all
> [ . . . ]
>>> This statement about TortoiseBzr is not correct.
>> oh?
>>
>>> Canonical spotted that
>>> development was stalled and have engaged Mark Hammond to pick things up
>>> and carry it to release, so there is paid help on the job now.  There is
>>> a release early, release often programme in place.
>> but it seems there are still no committs
>
> https://code.launchpad.net/~tortoisebzr-developers/tortoisebzr/tbzr2-proto
>
> Looks active to me.

http://bazaar-vcs.org/TortoiseBzr points to
https://code.launchpad.net/~amduser29/tortoisebzr/trunk, which has the
last activity in August 2007. Of course it is now clear to me, that
https://code.launchpad.net/~tortoisebzr-developers/tortoisebzr/tbzr2-proto 
is the right branch... but shouldn't that be corrected on
http://bazaar-vcs.org/TortoiseBzr? Because it is misleading

[...]

>>> Anyone can have a branch, that is the whole point of DVCS.  But there
>>> will always be one that the community accept as being the official state
>>> of software.
>> well, yes, sure... ut where are these branches physically? I more or
>> less came to this problem when hearing the google talk from Linus to
>> advocate GIT. He is pulling from others.. If I understand this right,
>> then there is some kind of remote repository and he is getting the
>> actual version from it. If not, then it would be a simple patch send by
>> for example email, or not? Bazaar seems not to work like this... at
>> least with the tools from above. It seems that then you have the patches
>> send to the mailing list and an automated tool will merge them. So there
>> is no need to access a remote repository. Am I worng about this?
>
> Branches can be anywhere.  Usually though they are accessible either
> over SSH or HTTP(S).  So for strictly controlled access branches you use
> the SSH access, HTTP gives public read-only access, and HTTPS+WebvDAV
> gives you controlled writeable access.
>
> Launchpad (for Bazaar), GitHub (for Git), Savannah (Bazaar, Mercurial or
> Git) all provide branch/repository hosting.  Hopefully soon so will
> Codehaus.
>
> Doing things with email and patch queues is another way instead of
> accessing .

ah, ok.. I think using ssh is not realistic. And not every developer can
host a webserver for usage with a DCVS.

bye blackdrag


--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Tue, 2008-07-01 at 15:31 +0200, Jochen Theodorou wrote:

> http://bazaar-vcs.org/TortoiseBzr points to
> https://code.launchpad.net/~amduser29/tortoisebzr/trunk, which has the
> last activity in August 2007. Of course it is now clear to me, that
> https://code.launchpad.net/~tortoisebzr-developers/tortoisebzr/tbzr2-proto 
> is the right branch... but shouldn't that be corrected on
> http://bazaar-vcs.org/TortoiseBzr? Because it is misleading

I have emailed the Bazaar list to ask that "something be done" to avoid
unfortunately bad advertising.

> > Branches can be anywhere.  Usually though they are accessible either
> > over SSH or HTTP(S).  So for strictly controlled access branches you use
> > the SSH access, HTTP gives public read-only access, and HTTPS+WebvDAV
> > gives you controlled writeable access.
> >
> > Launchpad (for Bazaar), GitHub (for Git), Savannah (Bazaar, Mercurial or
> > Git) all provide branch/repository hosting.  Hopefully soon so will
> > Codehaus.
> >
> > Doing things with email and patch queues is another way instead of
> > accessing .
>
> ah, ok.. I think using ssh is not realistic. And not every developer can
> host a webserver for usage with a DCVS.

For a FOSS project generally SSH is definitely a bad idea but for
branches to be shared but kept private it is great -- saves having to
run a Web server.  And indeed is far more secure than using HTTPS and
WebDAV since you can have accounts with no passwords but SSH key access.

Launchpad, GitHub, etc. show the way Codehaus, SourceForge, RubyForge,
etc. will be heading so that everyone can have branches but not host
them on their own servers that they do not have :-)

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: [phone], [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]

[Jochen Theodorou]

Russel Winder schrieb:
> On Tue, 2008-07-01 at 15:31 +0200, Jochen Theodorou wrote:
[...]

>>> Branches can be anywhere.  Usually though they are accessible either
>>> over SSH or HTTP(S).  So for strictly controlled access branches you use
>>> the SSH access, HTTP gives public read-only access, and HTTPS+WebvDAV
>>> gives you controlled writeable access.
>>>
>>> Launchpad (for Bazaar), GitHub (for Git), Savannah (Bazaar, Mercurial or
>>> Git) all provide branch/repository hosting.  Hopefully soon so will
>>> Codehaus.
>>>
>>> Doing things with email and patch queues is another way instead of
>>> accessing .
>> ah, ok.. I think using ssh is not realistic. And not every developer can
>> host a webserver for usage with a DCVS.
>
> For a FOSS project generally SSH is definitely a bad idea but for
> branches to be shared but kept private it is great -- saves having to
> run a Web server.  And indeed is far more secure than using HTTPS and
> WebDAV since you can have accounts with no passwords but SSH key access.
>
> Launchpad, GitHub, etc. show the way Codehaus, SourceForge, RubyForge,
> etc. will be heading so that everyone can have branches but not host
> them on their own servers that they do not have :-)

I think it is a bit strange.. int the days of cvs you almost never had
free cvs server. cvsdude is the only one I know. Anyway, if this goes
through Codehaus for example, then the user of course still needs access
to the server... I think I like the idea to use the mailing list to
handle patches and automatically merge after voting much better.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Tue, 2008-07-01 at 18:38 +0200, Jochen Theodorou wrote:

> I think it is a bit strange.. int the days of cvs you almost never had
> free cvs server. cvsdude is the only one I know. Anyway, if this goes
> through Codehaus for example, then the user of course still needs access
> to the server... I think I like the idea to use the mailing list to
> handle patches and automatically merge after voting much better.

In which case we could ask the Bazaar people whether the Codehaus people
could run Patch Queue Manager and Bundle Buggy, assuming the Codehaus
people are going to run Bazaar of course !

Of course there is an assumption here of using Bazaar.  I am not sure if
Mercurial has anything equivalent.    I suspect Git does not, but I am
guessing.
 
--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: [phone], [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]