[bt-devel] bazaar repo

[Jonathan Marsden]

Eeli Kaikkonen wrote:

> After some more difficulties the bazaar repo is still there but in a
> different shape. ...

Aha, that could explain why I am seeing:

bzr: ERROR: Target directory
bzr+ssh://jmarsden@bibletime.bzr.sourceforge.net/bzrroot/bibletime
already exists, but does not have a valid .bzr directory. Supply
--use-existing-dir to push there anyway.

errors whenever I try to push my commits back to it!

I'll throw away what I downloaded a day or two ago, bzr get again, and
then try the edit/commit/sign/push cycle again!

> If we want to start using a dvcs it means that only the bibletime
> subproject is in the repo, the rest will remain in svn until sf lets
> create several repos.

That's definitely the simplest solution.

Alternatively, you could decide that the only real overhead of the
single big repo is just a one-time initial download for each developer,
and so just keep it all together -- unless the web stuff changes a lot?
 As long as there aren't too many BT developers at the end of 9600bps
modems or very expensive Internet connections (!), that approach could
also be OK.

> I don't still know if it's possible or reasonable to keep two different
> vcs systems up to date. My personal opinion is that bzr or hg could just
> replace svn (except the hg win64 issue).

Agreed.  I'd vote for an eventual migration to bzr, if we were voting,
and if I had a vote :)

I don't think you want to try to keep two VCS systems synced, there
could be some nasty timing issues doing that, and it just seems like
extra work for no real benefit.  You could possibly keep a read-only svn
around, for users wanting to grab the development code to download from,
updated (say) nightly from the "real" DVCS; but having some developers
update using svn and some update using bzr (or whatever DVCS) and
somehow trying to keep two repos in sync... that sounds like a recipe
for trouble to me!

> Anyways, we don't of course make any sudden moves. Svn will stay for
> shorter or longer time, meanwhile we can keep testing others.

Right.  The optimal time for a switch is probably sometime after 2.0 is
out, and any immediate "oops!" issues arising from it are taken care of,
and the BT team is thinking about significant new features for 2.x ?

Jonathan