Fwd: Distributed RCS
With permission, I'm forwarding an email from Mark Shuttleworth about
Bazaar-2 (aka Bazaar-NG), a distributed source control system (not
entirely unlike bitkeeper, I presume) written in Python and in use by
the Ubuntu system. What do people think of using this for Python? Is
it the right model? Do we want to encourage widespread experimentation
with the Python source code?
--Guido van Rossum (home page: http://www.python.org/~guido/)
---------- Forwarded message ----------
From: Mark Shuttleworth
On Sat, Aug 13, 2005 at 02:27:22PM -0700, Guido van Rossum wrote:
What do people think of using this for Python?
I think it deserves consideration. One idea would be to have a Bazaar-NG repository that tracks the CVS SF repository. I haven't tried it yet but there is a tool called Tailor[1] that automates the task. That would give people a chance to experiment with Bazaar-NG (and still work with SF is down) without committing to it.
Is it the right model? Do we want to encourage widespread experimentation with the Python source code?
I think Python works fairly well with the centralized model. However, I expect it's hard to know what we are missing. Neil 1. http://darcs.net/DarcsWiki/Tailor
I have great hopes for baz-ng, but I don't know that it's really ready for
production use just yet. I don't know that we want to be right out on the
bleeding edge of revision control systems for Python.
The current bazaar, last time I looked (a few months ago) did not work on
Windows. This is a complete deal-breaker for us, unless we can agree to dump
that Windows support (who needs it, really? <wink>) I *hope* that baz-ng will
work fine on Windows - I haven't looked too closely at that side of it.
Anthony
--
Anthony Baxter
Anthony> The current bazaar, last time I looked (a few months ago) did Anthony> not work on Windows. This is a complete deal-breaker for us, I assume it would be a deal breaker for many people. According to the Bazaar-NG website it works on "Linux, Windows and Mac OS X, or any system with a Python interpreter". If it's that platform-independent, perhaps it will work on some systems that don't support CVS. It does require Python 2.4, though I doubt that would be a great hardship for many people interested in Python development. Skip
Guido van Rossum wrote:
With permission, I'm forwarding an email from Mark Shuttleworth about Bazaar-2 (aka Bazaar-NG), a distributed source control system (not entirely unlike bitkeeper, I presume) written in Python and in use by the Ubuntu system. What do people think of using this for Python? Is it the right model?
Like Skip, I tried experimenting with it. While that may be the right model, I don't think it is the right software. In bazaar-ng 0.0.5 (which is what Debian unstable currently has), bzr commit would not open a text editor, but require the commit message on the command line; selective commit of only some of the changed files is also not supported. bzr diff cannot show the changes between two revisions, and cannot show revisions across branches. So I assume that using bazaar-ng right now would cause problems in day-to-day usage. Regards, Martin
Martin> Like Skip, I tried experimenting with it. While that may be the Martin> right model, I don't think it is the right software. [problems Martin> elided] Martin> So I assume that using bazaar-ng right now would cause problems Martin> in day-to-day usage. Granted. What is the cost of waiting a bit longer to see if it (or something else) gets more usable and would hit the mark better than svn? I presume that once we switch away from cvs to something else, it's unlikely we would switch again unless some huge roadblock appeared that made the initial change the wrong one. I was amazed at the number of different version control systems out there now. CVS, while enormously successful from a practical standpoint, clearly has its detractors. That there are so many alternatives suggests that it's not clear yet what the "correct" feature set for a version control system is. Skip
skip@pobox.com wrote:
Granted. What is the cost of waiting a bit longer to see if it (or something else) gets more usable and would hit the mark better than svn? I presume that once we switch away from cvs to something else, it's unlikely we would switch again unless some huge roadblock appeared that made the initial change the wrong one.
It depends on what "a bit" is. Waiting a month would be fine; waiting two years might be pointless. So I think I will personally pursue PEP 347 (switching to SVN); it will be then an issue of BDFL pronouncement. Regards, Martin
On Sun, Aug 14, 2005 at 06:16:11PM +0200, "Martin v. Löwis" wrote:
It depends on what "a bit" is. Waiting a month would be fine; waiting two years might be pointless.
It looks like the process of converting a CVS repository to Bazaar-NG does not yet work well (to be kind). The path CVS->SVN->bzr would probably work better. I suspect cvs2svn has been used on quite a few CVS repositories already. I don't think going to SVN first would lose any information. My vote is to continue with the migration to SVN. We can re-evaluate Bazaar-NG at a later time. Neil
On 8/14/05, Neil Schemenauer
It looks like the process of converting a CVS repository to Bazaar-NG does not yet work well (to be kind). The path CVS->SVN->bzr would probably work better. I suspect cvs2svn has been used on quite a few CVS repositories already. I don't think going to SVN first would lose any information.
My vote is to continue with the migration to SVN. We can re-evaluate Bazaar-NG at a later time.
That's looks like a fair assessment -- although it means twice the conversion pain for developers. It sounds as if bazaar-NG can use a bit of its own medicine -- I hope everybody who found a bug in their tools submitted a patch! :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
It sounds as if bazaar-NG can use a bit of its own medicine -- I hope everybody who found a bug in their tools submitted a patch! :-)
I had problems finding the place where the bazaar-NG source code repository is stored - is there a public access to the HEAD version? There also doesn't appear to be a bug tracker - but I found a mentioning that bug reports should go to the mailing list. Regards, Martin
I had problems finding the place where the bazaar-NG source code repository is stored - is there a public access to the HEAD version?
You may use rsync: rsync -av --delete bazaar-ng.org::bazaar-ng/bzr/bzr.dev . Or bzr itself: bzr branch http://bazaar-ng.org/bzr/bzr.dev Regards, -- Gustavo Niemeyer http://niemeyer.net
Gustavo Niemeyer wrote:
You may use rsync:
rsync -av --delete bazaar-ng.org::bazaar-ng/bzr/bzr.dev .
Or bzr itself:
bzr branch http://bazaar-ng.org/bzr/bzr.dev
Ah, thanks. Fetching it with rsync is so much faster than fetching it with bzr, though... Regards, Martin
On Sun, 2005-08-14 at 11:12 -0600, Neil Schemenauer wrote:
On Sun, Aug 14, 2005 at 06:16:11PM +0200, "Martin v. Löwis" wrote:
It depends on what "a bit" is. Waiting a month would be fine; waiting two years might be pointless.
It looks like the process of converting a CVS repository to Bazaar-NG does not yet work well (to be kind). The path CVS->SVN->bzr would probably work better. I suspect cvs2svn has been used on quite a few CVS repositories already. I don't think going to SVN first would lose any information.
It doesn't. As a data point, CVS2SVN can handle gcc's massive cvs repository, which has merged rcs file information in it dating back to 1987, >1000 tags, and > 300 branches. Besides monotone's cvs_import, it's actually the only properly designed cvs converter I've seen in a while (Properly designed in that it actually uses the necessary and correct algorithms to get all the weirdities of cvs branches and tags right). I'm not sure how big python's repo is, but you probably want to use the attached patch to speed up cvs2svn. It changes it to reconstruct the revisions on it's own instead of calling cvs or rcs. For GCC, and KDE, this makes a significant difference (17 hours for our 4 gig cvs repo convresion instead of 52 hours), because it was spawning cvs/rcs 50 billion times, and the milliseconds add up :)
My vote is to continue with the migration to SVN. We can re-evaluate Bazaar-NG at a later time. GCC is moving to SVN (very soon now, within 2 months), and this has been my viewpoint as well.
It's much easier to go from something that has changesets and global revisions, to a distributed system, if you want to, than it is to try to reconstruct that info from CVS on your own :). Subversion also has excellent language bindings, including the python bindings. That's how i've hooked it up to gcc's bugzilla. You could easily write something to transform *from* subversion to another system using the bindings. Things like viewcvs use the python bindings to deal with the svn repository entirely. --Dan
Daniel Berlin wrote:
I'm not sure how big python's repo is, but you probably want to use the attached patch to speed up cvs2svn. It changes it to reconstruct the revisions on it's own instead of calling cvs or rcs.
Thanks for the patch, but cvs2svn works fairly well for us as is (in the version that was released with Debian sarge); see http://www.python.org/peps/pep-0347.html for the conversion procedure. On the machine where I originally did the conversion, the script required 7h; on my current machine, it is done in 1:40 or so, which is acceptable. Out of curiosity: do you use the --cvs-revnums parameter? Should we? Regards, Martin
On Mon, 2005-08-15 at 00:15 +0200, "Martin v. Löwis" wrote:
Daniel Berlin wrote:
I'm not sure how big python's repo is, but you probably want to use the attached patch to speed up cvs2svn. It changes it to reconstruct the revisions on it's own instead of calling cvs or rcs.
Thanks for the patch, but cvs2svn works fairly well for us as is (in the version that was released with Debian sarge); see
http://www.python.org/peps/pep-0347.html
for the conversion procedure. On the machine where I originally did the conversion, the script required 7h; on my current machine, it is done in 1:40 or so, which is acceptable.
Out of curiosity: do you use the --cvs-revnums parameter? Should we?
No. In our case, it doesn't buy us anything. In the name of continuity, we have to make the old cvsweb urls work with new viewcvs urls anyway (they appear in bug reports, etc). We also don't want to destroy the ability for people to diff existing cvs working copies. I may have been able to hack something around with cvs-revnums, but not easily. Thus, we are just going to keep a readonly version of the repo around, and a readonly cvsweb, with a warning at the top of the page that the current source is stored in subversion.
Regards, Martin
Martin v. Löwis wrote:
skip@pobox.com wrote:
Granted. What is the cost of waiting a bit longer to see if it (or something else) gets more usable and would hit the mark better than svn?
It depends on what "a bit" is. Waiting a month would be fine; waiting two years might be pointless.
This might be too convoluted to consider, but I thought I might throw it out there. We use svn for our repositories, but I've taken to also using bzr so I can do local commits and reversions (within a particular svn reversion). I can imagine expanding that usage to sharing branches and such via bzr (or mercurial, which looks great), but keeping the trunk in svn. -- Benji York
On Mon, 2005-08-15 at 04:30, Benji York wrote:
Martin v. Löwis wrote:
skip@pobox.com wrote:
Granted. What is the cost of waiting a bit longer to see if it (or something else) gets more usable and would hit the mark better than svn?
It depends on what "a bit" is. Waiting a month would be fine; waiting two years might be pointless.
This might be too convoluted to consider, but I thought I might throw it out there. We use svn for our repositories, but I've taken to also using bzr so I can do local commits and reversions (within a particular svn reversion). I can imagine expanding that usage to sharing branches and such via bzr (or mercurial, which looks great), but keeping the trunk in svn.
Not too convoluted at all; I already do exactly this with many upstream
CVS and SVN repositorys, using a local PRCS for my own branches. I'm
considering switching to a distributed RCS for my own branches because
it would make it easier for others to share them.
I think this probably is the best solution; it gives a reliable(?)
centralised RCS for the trunk, but allows distributed development.
--
Donovan Baarda
Like Skip, I tried experimenting with it. While that may be the right model, I don't think it is the right software. In bazaar-ng 0.0.5 (which is what Debian unstable currently has), bzr commit would not open a text editor, but require the commit message on the command line; selective commit of only some of the changed files is also not supported. bzr diff cannot show the changes between two revisions,
The development version has all of those features implemented already.
and cannot show revisions across branches.
I'm not sure about this one, though. -- Gustavo Niemeyer http://niemeyer.net
I encourage everyone to look at mercurial. It is also written in Python. I am using it daily.
participants (10)
-
"Martin v. Löwis" -
Anthony Baxter -
Benji York -
Daniel Berlin -
Donovan Baarda -
Guido van Rossum -
Gustavo Niemeyer -
Neal Becker -
Neil Schemenauer -
skip＠pobox.com