Mercurial for TG2 discussion
Mark Ramm
host ToscaWidgets.org there as well.
This seemed like a good idea to everybody responsible to the server,
but I raised the idea of switching TG2 to mercurial in a private
e-mail to the parties involved.
Obviously this is something that we should all talk about on the
mailing list before we even think seriously about making a switch in
our core development processes. So, here's my personal thinking so
far:
1) Alberto's got a neat setup on the toscawidgets site, where
mercurial, trac, and everything are all part of a single system with a
single username/password.
2) Alberto's setup would allow us to host trac sites for projects like
silverplate, or tg.ext.geo with their own mercurial repositories very
easily.
3) Mecurial's main advantages are easy branching/merging and the
ability to do commits offline
4) Pylons, Beaker, Routes, WebHelpers, and many other upstream
projects already use mercurial.
Chris Arent has brought up a couple of potential issues which we need
to think through:
1) Documentation would need to change
2) We would have to help people learn mercurial
3) Mercurial would need to be easy to install on all our target platforms
I think that there are binary installers for OS X and windows, and
RPM's and debs for all the major linux platforms. And mercurial is
python, so if you have all the nessisary stuff easy_install might even
work too, though it appears from Chris's e-mail to the list that it
might not always work.
There's a pretty good introduction to distributed version control at:
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
I'm sure there are some other issues surrounding the move to a more
distributed model. In fact, to prime the pump of that discussion,
here's a very old blog post by Ian Bicking explainining why he's not
100% sold on the distributed model.
http://blog.ianbicking.org/distributed-vs-centralized-scm.html
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
Gustavo Narea
On Tuesday 19 August 2008 15:12:54 Mark Ramm wrote:
> 1) Alberto's got a neat setup on the toscawidgets site, where
> mercurial, trac, and everything are all part of a single system with a
> single username/password.
You can do that with SVN and Trac too, by sharing the same Htpasswd file(s) -
or even using LDAP.
I don't see a big reason for avoiding Mercurial, yet I think this would not be
a big enhancement - it'd be an enhancement, but not a big one IMHO.
I'd go for a distributed VCS such as Bazaar or Mercurial if you really think
the time and effort needed to make the switch worth it.
Cheers.
--
Gustavo Narea.
General Secretary. GNU/Linux Matters.
http://www.gnulinuxmatters.org/
Steven Mohr
WinXp,Win2k3,Vista,Debian,Ubuntu,Solaris. I had no problems but I only
used it for checkouts, so I don't know anything about merging, commits
or something like that.
Diez B. Roggisch
> but I raised the idea of switching TG2 to mercurial in a private
> e-mail to the parties involved.
>
> Obviously this is something that we should all talk about on the
> mailing list before we even think seriously about making a switch in
> our core development processes. So, here's my personal thinking so
> far:
>
> 1) Alberto's got a neat setup on the toscawidgets site, where
> mercurial, trac, and everything are all part of a single system with a
> single username/password.
Nice for sure - but I don't find this as compelling as these admin-tasks
aren't so common. I say that as someone in responsibility for trac and svn
servers myself :)
> 2) Alberto's setup would allow us to host trac sites for projects like
> silverplate, or tg.ext.geo with their own mercurial repositories very
> easily.
I don't understand this. Do they use mercurial, which is why we can't host
them today?
> 3) Mecurial's main advantages are easy branching/merging and the
> ability to do commits offline
Can someone with mercurial experience provide some scenarios where using
mercurial over SVN is offering a really compelling advantage? I'm aware of
the offline-commits, but don't consider this as *to* important, simply
because anything that really counts is a commit into our server repository
(and that should be that way, otherwise we lose data if a local repository
gets corrupted), and at least I (and I think many if not most people) have
very frequent internet access.
So - what are the things you guys stumble upon developing TG2 and
thinking "boy, I wish it was mercurial"?
> 4) Pylons, Beaker, Routes, WebHelpers, and many other upstream
> projects already use mercurial.
Others use SVN. As do many projects that use TG and for example use
svn:externals.
Diez
Mark Ramm
> svn:externals.
Hmm, are there a lot of TG users who are using svn:externals to pull
TG in their own SVN setup?
I have not seen people doing this, but that doesn't mean it's not happening.
--Mark Ramm
Diez B. Roggisch
I for once used to do that with TG1.x before there was a release that
incorporated everything I needed - that's why I brought that up.
I don't consider this a killer-criteria - just something worth noticing that
might break in case of a switch.
In the end, my personal opinion is that I'm all open for new and better ways -
if they *are* new and better. And not just new :) For example, back in the
days CVS lacked directory and moving support. SVN provided this, and it's
well worth the upgrade. The much easier branching as well.
Diez
Dean Landolt
Sure, branching's a breeze in SVN but merging can be a little painful -- thus, the argument I typically hear for DVCS is just that. Merges are so easy it encourages everyone to work in their own sandbox for every distinct feature, constantly merging, pulling the mainline back in sync until the feature is done and tested and ready for a push back to mainline (or trunk, head, whatever). Arguably, there are a lot of benefits to this development strategy -- and it's just not so easy with SVN.
percious
really see a need for people to do a svn:externals for their own
projects. Simply check the trunk out and make your own egg and egg
basket. This is a formidable way of doing distribution of the trunk
code, because it freezes development at a place that will work for
your project.
I think SVN does not work well in the mode of development that
benefits TG2 the most: the sprint. Many of our sprints are held in
"pods" across the world. With a mecurial, git, or bzr repo, we can
have these pods committing locally to a on-site committer, negating
the need for passing around patches, or having everyone who is
involved in the sprint have a commit bit. In the past we have gotten
around this issue by creating a special user which everyone had the u/
p for, but I don't think this is a very good solution.
Obviously I am in favor of a distributed VCS system. I think Alberto
has created a highly useful integration between a website/trac/hg
repo, and if we can leverage that, I think we should. We may also
consider looking at git, and bzr, as HG has been getting some bad
press in the recent future.
cheers.
-chris
Daniel Fetchinson
Sounds like you've got a time machine.
Should I sell or buy? :)
Just kidding,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Kevin Horn
We have a new server for TurboGears.org, and Alberto asked if we could
host ToscaWidgets.org there as well.
This seemed like a good idea to everybody responsible to the server,
but I raised the idea of switching TG2 to mercurial in a private
e-mail to the parties involved.
OK, summing up my opinions:
HG Features:
1) Offline commits -- personally I don't have a need for this very often, but if needed this can be done using bzr + svn.
2) Merge tracking - SVN 1.5 has much improved merge tracking, and it should only get better in future.
3) Alberto's website/trac/hg integration - this is pretty trivial with SVN as well, I don't see anything that is all that different from what I'm using on several of my own projects.
4) Sprint development - bzr + svn could be a solution here too
One thing I just am ignorant about as far as hg: Does it "integrate" with setuptools like svn does? Can one do an "setup.py develop"?
I don't see a lot of technical reasons either for or against switching to HG, so as I see it, the relevant criteria boil down to:
1) How much work will it take to switch things over? And how much of that work could be spent on TG (and docs, etc.) instead?
2) How much disruption will this create in the developer community?
3) How much disruption will this create in the user community? (we have had a lot of users using SVN versions of TG in the past)
4) Is it really a good idea to encourage developers to work in their own little sandbox? There's lots of discussion on this around the net and I doubt very much that there's any "right" answer in general, but we need to decide whether this is "right" for the TG community.
5) Will this make it harder or easier to recruit new devs for TG?
Personally, I don't care much for HG, or distributed version control in general. But it's just my preference...as I said I don't see any technical reasons against the switch. But I don't see any technical reasons _for_ the switch either.
Of course, version control is a tool that the devs will primarily be concerned with. So really its up to them.
But when faced with these kinds of questions, I am inclined to be lazy ( though I call it "efficient" ;) )
Kevin Horn
gas...@gmail.com
> benefits TG2 the most: the sprint. Many of our sprints are held in
> "pods" across the world. With a mecurial, git, or bzr repo, we can
> have these pods committing locally to a on-site committer, negating
> the need for passing around patches, or having everyone who is
> involved in the sprint have a commit bit. In the past we have gotten
> around this issue by creating a special user which everyone had the u/
> p for, but I don't think this is a very good solution.
>
Besides, with HG web interface, people could get current
snapshot.tgz/.zip without check out the source repository.
It allows new developers to try the source without commitment, or
figure out how to check out the source code.
If there's a good policy to maintain the TG repository, I am +1 for
migrate to HG.
--
Fred
Jorge Godoy
>
> I think SVN does not work well in the mode of development that
> benefits TG2 the most: the sprint. Many of our sprints are held in
> "pods" across the world. With a mecurial, git, or bzr repo, we can
> have these pods committing locally to a on-site committer, negating
> the need for passing around patches, or having everyone who is
> involved in the sprint have a commit bit. In the past we have gotten
> around this issue by creating a special user which everyone had the u/
> p for, but I don't think this is a very good solution.
Keeping SVN and using SVK (that has a very similar command set) we can do the
same: create local branches, work on it doing several commits and then sync it
later to the main repository, keeping history of each and every commit.
> Obviously I am in favor of a distributed VCS system. I think Alberto
> has created a highly useful integration between a website/trac/hg
> repo, and if we can leverage that, I think we should. We may also
> consider looking at git, and bzr, as HG has been getting some bad
> press in the recent future.
If it is to buy mobility at sprints, then I'd rather use SVK and keep
everything as it is now. If there is any other reason, then I'd like to
understand it as well.
--
Jorge Godoy <jgo...@gmail.com>
Jorge Godoy
> Besides, with HG web interface, people could get current
> snapshot.tgz/.zip without check out the source repository.
> It allows new developers to try the source without commitment, or
> figure out how to check out the source code.
Just like they can do with a read only access on CVS and SVN, right?
cvs export ...
subversion export ...
No need for a DVCS for that.
Latest snapshot? Lots of projects make a "nightly" tarball available. If
there's no commitment there's no need to get the changes from 30s ago on the
tarball...
--
Jorge Godoy <jgo...@gmail.com>
Jorge Vargas
> Em Tuesday 19 August 2008 12:50:57 percious escreveu:
>>
>> I think SVN does not work well in the mode of development that
>> benefits TG2 the most: the sprint. Many of our sprints are held in
>> "pods" across the world. With a mecurial, git, or bzr repo, we can
>> have these pods committing locally to a on-site committer, negating
>> the need for passing around patches, or having everyone who is
>> involved in the sprint have a commit bit. In the past we have gotten
>> around this issue by creating a special user which everyone had the u/
>> p for, but I don't think this is a very good solution.
>
> Keeping SVN and using SVK (that has a very similar command set) we can do the
> same: create local branches, work on it doing several commits and then sync it
> later to the main repository, keeping history of each and every commit.
>
(other than push/pull for obvious reasons) that is really different is
hg revert which doesn't do what you think it does.
>> Obviously I am in favor of a distributed VCS system. I think Alberto
>> has created a highly useful integration between a website/trac/hg
>> repo, and if we can leverage that, I think we should. We may also
>> consider looking at git, and bzr, as HG has been getting some bad
>> press in the recent future.
>
> If it is to buy mobility at sprints, then I'd rather use SVK and keep
> everything as it is now. If there is any other reason, then I'd like to
> understand it as well.
yes indeed, in fact you can do this with mercurial too, it's build-in
convert tool is getting better with every release I have been doing
that for some time
http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion
>
>
> --
> Jorge Godoy <jgo...@gmail.com>
>
>
>
Jorge Vargas
>
> We have a new server for TurboGears.org, and Alberto asked if we could
> host ToscaWidgets.org there as well.
>
> This seemed like a good idea to everybody responsible to the server,
> but I raised the idea of switching TG2 to mercurial in a private
> e-mail to the parties involved.
>
> Obviously this is something that we should all talk about on the
> mailing list before we even think seriously about making a switch in
> our core development processes. So, here's my personal thinking so
> far:
>
- mercurial is much faster on operations (hg diff, etc.)
- branches, especially private ones, are awesome. For example I run my
own webhelpers private branch for one of my GAE projects, I got full
rev history, I can commit whatever I want, everything works. If some
of that code needs to move out into webhelpers tip, export/import and
done, and if some of that code is too specific for my app (or the
maintainers of tip don't want it) I can keep it without any troubles.
- hgwebdir is a great tool, the closest thing to it on the svn world is trac.
- there is no fricking .svn on every folder. I use grep a lot and that
annoys me a LOT.
- in theory there is less chance of breaking the trunk,tip as you will
commit a set of changes that actually work. Even better if we have
someone in charge of doing code reviews he could filter bad commits.
this one is kind of a shocker:
- you don't need to be distributed if all developers push their
changes after commits, you get all the goodies and are still
"centralized".
- you can have and maintain private forks better, I know this one
isn't a biggie for an open source project but it's good for the hybrid
model most of us use (charge customers for software build on open
source).
- I always found the /trunk /branches/ /tags hardcoded dirs a bad idea
for my projects. Ones it gets large you either have to make your /
grow a lot, or start checking out your trunk, and the branches you are
actually working on. On the other hand mercurial manages this
transparently.
- You can rebuild from crashes (or as it happen to me, getting locked
out of the server, I lost a lot of revision history on svn ones) with
mercurial this will never happen.
- the learning curve is minimal, almost all svn commands map 1-1 to hg
commands, so the only thing you need to learn is all the goodies hg
has, the only exception I can think of is hg revert.
now here is why I think it will be good for TG
- take a look at http://svn.turbogears.org/ we have at least 6-7
projects on that first level. If you go to
http://svn.turbogears.org/projects/ it's over 20. to svn they are all
the same thing. Now why we got there? because svn is very complex to
administer and having multiple repo's it's a pain.
- so this means that someone working on TG1, TG2 and some of the extra
packages will have to check out several parts of that big repo, which
is clumsy, you know it is.
- RSS feeds customized per project, for free
- TG1 refuses to die (no offense) and now that it has gone to CP3 I
don't think it will be gone in a near future, which means that TG1 and
TG2 will live together, having each on it's own repo and merging
changes from one to the other (if any) will be very easy.
- we could host our own copies of upstream repo's, this is good in
case it's unreliable, unavaliable or even worst goes closed source
- forks are good :) seriously if for some reason we need to fork
(temporally) from any of the pylons's components it can be done and
then the same release process for TG can be maintain.
------------------------
As for hg on windows, I don't have a lot of direct experience but I
did a lot of research to swith over one of my repo's where a client
(read not-that-technical user) needed to commit some changes to the
template files, I remember I had to build an elaborate hooks structure
for me to review her "code", it wasn't very nice. Anyway when I
decided to switch to hg, I looked around and I was impress with how
good windows support is tortoiseHG is much better than tortoiseSVN,
they even have GTK dialogs that work on linux! and on the backend I
don't have useless comments on my main's repo commit log :)
So as you can tell I'm a big +1 on hg
Lee McFadden
while now and I've ditched SVN for it for as many projects as I could.
It's faster than SVN for almost everything and doesn't require
internet access for those times when you want to code while traveling.
On a subjective note, it matches my workflow a lot better. If I had a
penny for every time I wished I could have an intermediary commit
before sending something to the main repo while using SVN...
--
Lee McFadden
blog: http://www.splee.co.uk
rejaw: http://rejaw.com/splee
twitter: http://twitter.com/splee
Jorge Godoy
>
> - branches, especially private ones, are awesome. For example I run my
> own webhelpers private branch for one of my GAE projects, I got full
> rev history, I can commit whatever I want, everything works. If some
> of that code needs to move out into webhelpers tip, export/import and
> done, and if some of that code is too specific for my app (or the
> maintainers of tip don't want it) I can keep it without any troubles.
Other DVCS that are compatible with SVN would allow you to do the same without
any change to the main repository -- i.e., you could get that without
impacting everyone else.
> - hgwebdir is a great tool, the closest thing to it on the svn world is
> trac.
So it also allows you to have a Wiki with docs, bug tracking system and
everything else that Trac does? Or is it a minimized version of Trac but with
a better file navigator? What would better file navigation bring to the
project that would justify "changing" from SVN to HG?
> - there is no fricking .svn on every folder. I use grep a lot and
> that annoys me a LOT.
Yep. I have a "grep -v .svn" alias for that. :-)
> - in theory there is less chance of breaking the trunk,tip as you will
> commit a set of changes that actually work. Even better if we have
> someone in charge of doing code reviews he could filter bad commits.
> this one is kind of a shocker:
I didn't get this. What will prevent someone from commiting bad code? In my
experience the only thing that does that is the requirement that unit tests be
coded and then have then run on a commit hook, rejecting the commit if
anything fails (and then nothing prevents the unit test from being deleted /
not written and having bad code commited).
Reverting bad changes is doable in all VCS.
> - you don't need to be distributed if all developers push their
> changes after commits, you get all the goodies and are still
> "centralized".
Problem here is the "if". According to Murphy's law, this won't happen so
you'll end up with fragmented sources for code.
> - you can have and maintain private forks better, I know this one
> isn't a biggie for an open source project but it's good for the hybrid
> model most of us use (charge customers for software build on open
> source).
You charge your customers for TG code that you write?
> - I always found the /trunk /branches/ /tags hardcoded dirs a bad idea
> for my projects. Ones it gets large you either have to make your /
> grow a lot, or start checking out your trunk, and the branches you are
> actually working on. On the other hand mercurial manages this
> transparently.
I couldn't understand what you were trying to say. If you could explain it
better, I'd appreciate. The names you cite are just a convention and aren't a
requirement for anything. We (human beings) do that because we like grouping
similar things. This arrangement uses disk savvy implementations so there's
no loss here.
> - You can rebuild from crashes (or as it happen to me, getting locked
> out of the server, I lost a lot of revision history on svn ones) with
> mercurial this will never happen.
Never? Hard to believe.
Anyway, if you don't use the DB option and uses "fsfs" type for storing files
then you can simply back them up and restore as you do with any file on your
hard drive. There will be no DB corruption (there's no DB).
> - the learning curve is minimal, almost all svn commands map 1-1 to hg
> commands, so the only thing you need to learn is all the goodies hg
> has, the only exception I can think of is hg revert.
"almost", "exception"...
> - take a look at http://svn.turbogears.org/ we have at least 6-7
> projects on that first level. If you go to
> http://svn.turbogears.org/projects/ it's over 20. to svn they are all
> the same thing. Now why we got there? because svn is very complex to
> administer and having multiple repo's it's a pain.
I don't think so. I think that this got to be like that because we didn't
care to plan for this type of contribution. Creating a new repository is just
a matter of running one shell script with a batch of commands and that's it.
You can even automate Trac creation and configuration (I do that, it works
really well).
> - so this means that someone working on TG1, TG2 and some of the extra
> packages will have to check out several parts of that big repo, which
> is clumsy, you know it is.
Is it? I'd thik it would be clumsier to go to different servers
(repositories, whatever) to get all components (specially "if" they are not
commited to the central server).
> - RSS feeds customized per project, for free
Doable with post-commit hooks. Configuration automated by the same shell
script mentioned above...
> - TG1 refuses to die (no offense) and now that it has gone to CP3 I
> don't think it will be gone in a near future, which means that TG1 and
> TG2 will live together, having each on it's own repo and merging
> changes from one to the other (if any) will be very easy.
Isn't it easy today? Just merge... Why switching tools will make it easier?
> - we could host our own copies of upstream repo's, this is good in
> case it's unreliable, unavaliable or even worst goes closed source
Copying the whole history of commits since day 1? I don't see how that could
be useful if it goes closed source... Having the latest code would be the
most important thing... The only benefit is if you want to fork some code and
only decides doing that after the licensing change.
> - forks are good :) seriously if for some reason we need to fork
> (temporally) from any of the pylons's components it can be done and
> then the same release process for TG can be maintain.
Same can be done with other DVCS without any change on the existing
repository.
I have the same question that I posted on the other list: What will changing
the main repository from on VCS to another gives us? I haven't seen anything
that can't be obtained today.
--
Jorge Godoy <jgo...@gmail.com>
Andrew Grover
> I have the same question that I posted on the other list: What will changing
> the main repository from on VCS to another gives us? I haven't seen anything
> that can't be obtained today.
It allows people without commit access to track development and make
improvements. This can be worked around but it's not as good as having
the main repo actually being distributed. Early on with TG I tried
SVK, and personally hated it. Today I use git-svn, it let's me pretend
SVN is git :-) But hg is a better fit for a python project than git so
I'd love to see TG switch to hg.
Regards -- Andy
Jorge Vargas
> Em Friday 22 August 2008 04:16:53 Jorge Vargas escreveu:
>>
>> - branches, especially private ones, are awesome. For example I run my
>> own webhelpers private branch for one of my GAE projects, I got full
>> rev history, I can commit whatever I want, everything works. If some
>> of that code needs to move out into webhelpers tip, export/import and
>> done, and if some of that code is too specific for my app (or the
>> maintainers of tip don't want it) I can keep it without any troubles.
>
> Other DVCS that are compatible with SVN would allow you to do the same without
> any change to the main repository -- i.e., you could get that without
> impacting everyone else.
>
in fact it has several ways
http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion
The suggestion here is to eliminate having SVN + something else, and
replace everything with just a DVCS.
>> - hgwebdir is a great tool, the closest thing to it on the svn world is
>> trac.
>
> So it also allows you to have a Wiki with docs, bug tracking system and
> everything else that Trac does? Or is it a minimized version of Trac but with
> a better file navigator? What would better file navigation bring to the
> project that would justify "changing" from SVN to HG?
>
because when someone wants to publish his own branch trac is
suboptimal, in the end is just too complicated for a temporal repo to
show off some idea.
>> - there is no fricking .svn on every folder. I use grep a lot and
>> that annoys me a LOT.
>
> Yep. I have a "grep -v .svn" alias for that. :-)
>
>> - in theory there is less chance of breaking the trunk,tip as you will
>> commit a set of changes that actually work. Even better if we have
>> someone in charge of doing code reviews he could filter bad commits.
>> this one is kind of a shocker:
>
> I didn't get this. What will prevent someone from commiting bad code? In my
> experience the only thing that does that is the requirement that unit tests be
> coded and then have then run on a commit hook, rejecting the commit if
> anything fails (and then nothing prevents the unit test from being deleted /
> not written and having bad code commited).
>
Since we have several people pulling changes from other repo's you
have more eyes looking at the code. On top of that if the stable repo
has flew people on it (for example only the maintainer of the branch)
then it means that person will review all changes that go into that
repo. Since code is moved around a lot more people see it which as
linux (the kernel) has shown us reduces the amount of bugs push out.
> Reverting bad changes is doable in all VCS.
>
that fixing the problem after it happens, not preventing it.
>
>> - you don't need to be distributed if all developers push their
>> changes after commits, you get all the goodies and are still
>> "centralized".
>
> Problem here is the "if". According to Murphy's law, this won't happen so
> you'll end up with fragmented sources for code.
>
This is not true, if you forget to push your changes to the tg server
then too bad for you, you won't get on the release notes. there is no
way (unless intentional) that you could push half a feature into tip.
Well actually there is you can do export/import but that goes into the
intentional.
>> - you can have and maintain private forks better, I know this one
>> isn't a biggie for an open source project but it's good for the hybrid
>> model most of us use (charge customers for software build on open
>> source).
>
> You charge your customers for TG code that you write?
>
sorry I left out a word there that mislead you "build on top of open
source". Anyway what I wanted to say here is represented by the
following scenario:
you find a bug and fix it (with tests and everything), you open a
ticket in trac, because you want someone to review it (or worse you
don't have commit access), now you need to deploy said app with this
patched TG. In a centralized system you will have to remind everyone
(or write a script) to run your patch every time something is
installed. In a distributed world you just clone the repo and the rest
of the process is exactly the same.
of course you could just generate egg files from the patched trunk but
that means distributing things and a bunch of complications you don't
get by just using several repositories.
>> - I always found the /trunk /branches/ /tags hardcoded dirs a bad idea
>> for my projects. Ones it gets large you either have to make your /
>> grow a lot, or start checking out your trunk, and the branches you are
>> actually working on. On the other hand mercurial manages this
>> transparently.
>
> I couldn't understand what you were trying to say. If you could explain it
> better, I'd appreciate. The names you cite are just a convention and aren't a
> requirement for anything. We (human beings) do that because we like grouping
> similar things. This arrangement uses disk savvy implementations so there's
> no loss here.
>
Yes indeed there is no requirement for the above structure (although
everyone does it) and disk-wise there isn't a problem either. The
problem is visually why do I have to have that structure? why tags
need to sit around in directories when they can be hidden inside the
.hg dir? trunk/branches&tags are human conventions as you said, now do
you have a checkout of the whole directory structure of TG? no one
does that therefore you end up with a bunch of checkouts which
represent a part of the repo which isn't very nice. This falls into
the "I don't like it" category so your free to disagree :)
>> - You can rebuild from crashes (or as it happen to me, getting locked
>> out of the server, I lost a lot of revision history on svn ones) with
>> mercurial this will never happen.
>
> Never? Hard to believe.
you never lost credentials to a server? good for you, it's not very nice.
>
> Anyway, if you don't use the DB option and uses "fsfs" type for storing files
> then you can simply back them up and restore as you do with any file on your
> hard drive. There will be no DB corruption (there's no DB).
>
most hosting providers back things up at most ones every day, TG
current is 1 per day, 1 per week if I recall correctly. which means a
crash & restore from backup could potentially lose you 1 full day of
changes. the fact that each mercurial repo is a backup means there is
zero chance of losing any code that was live at the site.
>> - the learning curve is minimal, almost all svn commands map 1-1 to hg
>> commands, so the only thing you need to learn is all the goodies hg
>> has, the only exception I can think of is hg revert.
>
> "almost", "exception"...
>
yes 1 exception. is that enough not to switch? if so then why didn't
we stick with CVS. it's "almost" the same as svn, with some
"exceptions" like proper rename, and no locks.
>> - take a look at http://svn.turbogears.org/ we have at least 6-7
>> projects on that first level. If you go to
>> http://svn.turbogears.org/projects/ it's over 20. to svn they are all
>> the same thing. Now why we got there? because svn is very complex to
>> administer and having multiple repo's it's a pain.
>
> I don't think so. I think that this got to be like that because we didn't
> care to plan for this type of contribution. Creating a new repository is just
> a matter of running one shell script with a batch of commands and that's it.
The first problem is that trac (main released stable non-patched)
can't handle multiple svn repositories so the one shell script doesn't
happens, so having several svn repositories isn't that simple.
>
> You can even automate Trac creation and configuration (I do that, it works
> really well).
>
yes this is one of Mark's original points. Alberto did it for
toscawidgets.org and he did a great job at it so (he said) we should
use it. Did you did the same for svn?
>> - so this means that someone working on TG1, TG2 and some of the extra
>> packages will have to check out several parts of that big repo, which
>> is clumsy, you know it is.
>
> Is it? I'd thik it would be clumsier to go to different servers
> (repositories, whatever) to get all components (specially "if" they are not
> commited to the central server).
>
why you say that. it's not like we are going to have a zillion repo's
in a zillion servers. they are all going to be in hg.turbogears.org
(or whatever it ends up being), and they all have the same place. Take
a look at http://pylonshq.com/hg
if you want webhelpers you checkout the following URL
http://pylonshq.com/hg/webhelpers/ if you want pylons trunk you go
here http://pylonshq.com/hg/pylons-dev/ how is that different from
tg's svn? from the user perspective it's exactly the same. From the
developer perspective it's a whole different thing with independent
repo's and commit numbers, totally atomic clones and no way to leak
from one part to the other.
>> - RSS feeds customized per project, for free
>
> Doable with post-commit hooks. Configuration automated by the same shell
> script mentioned above...
>
but not out of the box. where is it now? oh yes in a tg-tickets
mailing list that stop working a while ago and the keys got lost.
>> - TG1 refuses to die (no offense) and now that it has gone to CP3 I
>> don't think it will be gone in a near future, which means that TG1 and
>> TG2 will live together, having each on it's own repo and merging
>> changes from one to the other (if any) will be very easy.
>
> Isn't it easy today? Just merge... Why switching tools will make it easier?
>
because DVCS merge kicks svn's ***, you don't have to ask me everyone
agrees on that. which is why svn1.5 worked so much on fixing it a
little.
>> - we could host our own copies of upstream repo's, this is good in
>> case it's unreliable, unavaliable or even worst goes closed source
>
> Copying the whole history of commits since day 1? I don't see how that could
> be useful if it goes closed source... Having the latest code would be the
> most important thing... The only benefit is if you want to fork some code and
> only decides doing that after the licensing change.
how about the unreliable and unavailable?
As for having everything since day 1, ones a bug is found in
trunk/tip/whatever you need to go back to all the deployed stuff and
fix it. Which means knowing when the bug was introduced is a huge plus
since you only need to patch from that day to know. Some app's stay up
for a lot longer than what someone could think of.
>
>> - forks are good :) seriously if for some reason we need to fork
>> (temporally) from any of the pylons's components it can be done and
>> then the same release process for TG can be maintain.
>
> Same can be done with other DVCS without any change on the existing
> repository.
>
again, the proposition here is to eliminate the need for svk or
git-svn or hg-svn, and just keep everything speaking the same
language.
>
>
> I have the same question that I posted on the other list: What will changing
> the main repository from on VCS to another gives us? I haven't seen anything
> that can't be obtained today.
>
All 4 of Mark's original ideas are valid, plus offline commits as
several others have suggested, plus the ideas I posted that you didn't
reject, plus the ones where I think your objections are not valid :)
>
>
> --
> Jorge Godoy <jgo...@gmail.com>
>
>
>
Jorge Godoy
> All 4 of Mark's original ideas are valid, plus offline commits as
> several others have suggested, plus the ideas I posted that you didn't
> reject, plus the ones where I think your objections are not valid :)
I am not rejecting anything. I am playing the Devil's advocate here.
Somebody has to make us all think and plan, even if this person is labeled as
annoying and boring :-)
We will be asked that, we'll have to justify the change and we have to be sure
it is worth it, not just something fancy that everybody is doing.
There are great projects out there that still uses CVS and they are doing very
well.
If most people want to switch, I am not the one who will prevent the change.
But I am questioning if it is the right moment, the right decision and if our
reasoning for the change is valid.
Regards,
--
Jorge Godoy <jgo...@gmail.com>
Jorge Vargas
Em Thursday 28 August 2008 02:50:06 Jorge Vargas escreveu:
> All 4 of Mark's original ideas are valid, plus offline commits asI am not rejecting anything. I am playing the Devil's advocate here.
> several others have suggested, plus the ideas I posted that you didn't
> reject, plus the ones where I think your objections are not valid :)
Somebody has to make us all think and plan, even if this person is labeled as
annoying and boring :-)
yea I know it has been the case (several times) where you take that position and I know it's for the greater good.
We will be asked that, we'll have to justify the change and we have to be sure
it is worth it, not just something fancy that everybody is doing.
There are great projects out there that still uses CVS and they are doing very
well.
yes indeed, great code is not determine by the tools around it.
If most people want to switch, I am not the one who will prevent the change.
But I am questioning if it is the right moment, the right decision and if our
reasoning for the change is valid.
totally valid point. Which is why it's being discuss in the open.
Leandro Lucarella
> On Thu, Aug 28, 2008 at 4:48 PM, Jorge Godoy <jgo...@gmail.com> wrote:
> > There are great projects out there that still uses CVS and they are doing
> > very
> > well.
>
> yes indeed, great code is not determine by the tools around it.
But it helps. If a tool make your life miserable to do the things right
(like amend a patch or have freedom to make all the patches you want
without connecting to the server, etc), it's much more harder to have,
maybe not great code, but a great development process, which usually
impacts in the code one way or other.
I wonder why you don't consider git (I guess it's the not-so-good Windows
support). It's such a great tool, rebase -i is a life changer (I never
used Mercurial, though, so I don't know if it has something similar)
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Sus discipulos se miraron sin entended hasta que uno preguntose:
Peperino, soy Daniel Q. de Olivos tengo 54 años y aún soy virgen. A lo
que Peperino respondiole: Si sos ganso, ganso ser. Y lo frotó, y lo
curó y lo sanó. A lo que todos dijeron: ¡¡¡Peperino se la come,
Peperino se la come!!!
-- Peperino Pómoro
Mark Ramm
interest in making our development process as accessible and easy to
get involved as possible, and I think that lots of good points and
counterpoints have been raised. But, I also think it's time to get
on with the work of developing the best web framework that we can.
So, let me summarize the important issues from this thread, and make a
suggestion on how to move forward.
Points in favor of Mercurial:
1) Florent, Mark, Alberto, Jorge V. Percious, Lee McFadden all have
used mercurial in the past and have given a +1
2) The killer feature for Mercurial is easy branching and merging,
this reduces the cost of experimentation.
3) The other killer feature of Mercurial is that it makes it easier to
accept even large contributions from someone without "commiter
rights."
4) Mercurial has integration with buildout and other tools in our toolchain.
5) Documentation on how to contribute to TurboGears will have to be update
6) Alberto has some interesting integration stuff that makes it easy
to publish new repositories and setup separate committer auth for
those repositories.
7) Sprints become way, way easier to manage because everybody can
commit to a local sprint repository.
Disadvantages of switching:
1) TG contributers need to learn a new tool.
2) TG contribution documentation needs to be changed
3) The process could become more confusing and chaotic, if people go
around publishing branches of their own.
A couple of alternatives to mercurial were suggested. SVK would work
on top of the existing infrastructure and provide some of the same
benifits. But I see a couple of disadvantages here. SVK is harder
to install and maintain, and is slower than mercurial. It's also not
been well maintained as an open source project and I am hesitant to
invest our collective energy in using it when it's very likely that it
will wither and die.
Another suggested alternative is bazaar, and this is a much more
compelling story on some fronts. There is a bzr svn plugin that lets
bzr treat a svn repository as a branch, so we could use that to
maintain our existing svn repository structure but get some bzr
advantages. Also the launchpad integration is nice.
But, I think mercurial is a better choice for us because it's being
used by more upstream projects, and because we have the mercurial
integration that alberto wrote for TW.
It's also been suggested that a switch to hg will require us to have
stricter policies about how we handle the "main repository" but I
think our current practice will just become policy. There would be a
central hg repository for tg2, and the same people would have commit
access to it as the current svn repository. Only stable agreed upon
features should go in that repository. And branches created for
experimentation should be published on the tg servers if they are
expected to have public visibility.
So, with all that summary, it seems to me pretty clear that a switch
to hg has some significant advantages, and the disadvantages are
pretty easily overcome. What excites me most about the switch is
that we can make it significantly easier to make large contributions
to TurboGears, without needing to ask for commit access first. And I
want to encourage experamentation, exploration, and to make it as easy
as possible to get involved.
With all that said, I think I'm pretty well convinced that a switch to
mercurial is in our future. My suggestion is that we move "trunk",
and "projects/tg.devtools' into mercurial first, and that we work on
getting Alberto's setup working on our servers, and see how things go.
If there are any strong objections that didn't come up in the
discussion, please jump in now.
Diez B. Roggisch
> mercurial is in our future. My suggestion is that we move "trunk",
> and "projects/tg.devtools' into mercurial first, and that we work on
> getting Alberto's setup working on our servers, and see how things go.
>
> If there are any strong objections that didn't come up in the
> discussion, please jump in now.
I don't mind the switch - all I'd like to see is that it is done *after* a
first TG2 release has been done. I (and I don't doubt many others) have
SVN-based installations. I can constantly update, and provide patches if
needed.
Changing this would have a noticeable impact on this, and I don't think that
should happen as long as people have to rely on SVN to have something working
at all.
Additionally, it might be worth considering not to spread the resources right
now on more than one "battleground" - while I don't see any reasons that
things won't go rather smooth, they certainly are time-consuming to some
extend.
Diez
Christopher Arndt
> Disadvantages of switching:
>
> 1) TG contributers need to learn a new tool.
>
> 2) TG contribution documentation needs to be changed
>
> 3) The process could become more confusing and chaotic, if people go
> around publishing branches of their own.
Plus:
we either need to switch TG2 and TG1.x together* or we need
- two tracs
- two buildbots
- possibly two user management systems
If we want to switch TG 1.x to mercurial we need to change a lot of
things in the build process.
On the other hand, if we have a totally different project infrastructure
for TG2 and TG 1.x, it might become more difficult to share efforts.
Chris
Leandro Lucarella
> A couple of alternatives to mercurial were suggested. SVK would work
> on top of the existing infrastructure and provide some of the same
> benifits. But I see a couple of disadvantages here. SVK is harder
> to install and maintain, and is slower than mercurial. It's also not
> been well maintained as an open source project and I am hesitant to
> invest our collective energy in using it when it's very likely that it
> will wither and die.
>
> Another suggested alternative is bazaar, and this is a much more
> compelling story on some fronts. There is a bzr svn plugin that lets
> bzr treat a svn repository as a branch, so we could use that to
> maintain our existing svn repository structure but get some bzr
> advantages. Also the launchpad integration is nice.
Some words about git (to add some more salt to the discussion :).
git svn is a great tool for migration/git-svn coexistence. With git svn
you even can keep the svn as the "real trunk" and do all the branching in
a git repository, completely maintaining "backward compatibility" for
people using svn. This is great for any migration (specially, users minds
migration =).
For example:
I can do: $ git svn clone http://svn.turbogears.org/trunk/ tg
Now I have a git repository with all the tg's trunk svn history.
I can do git branch, git commit, etc. It's just a git repository to me.
When I have a branch ready for "upstream commit", I just can make:
$ git svn rebase # aka svn update
$ git svn dcommit # aka svn commit on steroids
git svn rebase, pull all the new changes from the svn repository, and
rebase my changes over them. git svn dcommit commit every local git commit
that's not in svn to "upstream" svn (you can manipulate svn branches too,
I don't include it in the example to keep it simple).
So, if you publish you git repository, you are now migrated to git, and
people can clone the git repository, do their own branches, do their local
commits, send you patches via email using git send-email, publish their
branches so you can pull them and be happy in general.
As long as there is only one "entry point" (or "sync point") between the
svn repo and the git one, people can still make commits to the svn trunk,
and keep doing their lifes without even knowing that a git repo exists.
They can do svn updates and checkout too, of course. All you have to do is
a git svn rebase on the "official git repo" and all the people who has
cloned it, can see the changes too.
I found this feature very useful and successful in migrating svn repos to
git.
I don't mean to add more noise to an already hard decision, but I thought
you should know the git goodies (if you don't already know them) before
you decide about a new SCM =)
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
So you run and you run to catch up with the sun but it's sinking.
Racing around to come up behind you again.
The sun is the same in a relative way but you're older,
Shorter of breath and one day closer to death.
Mark Ramm
> you even can keep the svn as the "real trunk" and do all the branching in
> a git repository, completely maintaining "backward compatibility" for
> people using svn. This is great for any migration (specially, users minds
> migration =).
Yes, but git's windows support makes it a non-starter for us.
bzr-svn provides a similar functionality, and it works on windows reliably.
Mark Ramm
>
> - two tracs
> - two buildbots
> - possibly two user management systems
>
> If we want to switch TG 1.x to mercurial we need to change a lot of
> things in the build process.
Good point.
My thought was that we would need to be running two tracs, etc,
because we'd also be hosting toscawidgets which is hg based. And
we'd want to use tg2 as a test-bed for hg migration before we move the
larger and more complicated set of tg1 stuff over.
But perhaps that's not as good an idea as i think it is.
> On the other hand, if we have a totally different project infrastructure
> for TG2 and TG 1.x, it might become more difficult to share efforts.
Possibly, though I think that we should be keeping tg1 and tg2 tickets
seprate anyway, and code rarely flows back and forth between trunk and
any of the tg1 related branches, so I don't really think this will be
a huge issue.
--Mark Ramm
Mark Ramm
> first TG2 release has been done. I (and I don't doubt many others) have
> SVN-based installations. I can constantly update, and provide patches if
> needed.
Yea, it makes sense to me to do this post 1.9.7 final, or at least to
maintain the current svn repository as the authoritative version until
after the final is released. Publishing a semi-official hg
repository alongside the svn repo may be a reasonable interum step.
We can easily push changes back and forth between hg and mercurial, we
just loose some history in the process.
--Mark Ramm
Christopher Arndt
>> On the other hand, if we have a totally different project infrastructure
>> for TG2 and TG 1.x, it might become more difficult to share efforts.
>
> Possibly, though I think that we should be keeping tg1 and tg2 tickets
> seprate anyway, and code rarely flows back and forth between trunk and
> any of the tg1 related branches, so I don't really think this will be
> a huge issue.
What about projects hosted on turbogears.org that are used by TG1 and
TG2? TurboJson springs to mind. Where should they reside? Or should we
leave that up to the project maintainer (which in TJ's case is the TG 1
release team, furthermost Christoph Zwerschke).
Chris
Mark Ramm
I think we should migrate those out of the TG repository as project
maintainers decide. But my suggestion for the first step is just to
do trunk and tg.devtools.
--Mark
Andrew Basson
This discussion sounds a little like RHEL (TG1) and Fedora (TG2).
Suggest you keep the existing TG1.x infrastructure on SVN. Split TG2
trac and repo out.
Perhaps setup trac1.turbo... and trac2.turbo... for the different
versions? trac.turbo... just points to trac1.turbo...
Allows the bleeding edge types who want to experiment the full flexabilty of hg.
Just my 2 cents. I don't spend much time on python or use CVS/SVN/hg
in my day job to comment further. I enjoy the passion and excitement
of this group and the ideals you are all trying to achieve. I loved
being able to use TG trunk to construct an Operations Monitoring tool
that has given us visibility into monthly batch processing runs that
we never had before. The MVC in python and templating sure beats PERL
anyday. At least I can go back to the python code and understand it...
Keep up the good work on all fronts.
Andrew.
Alberto Valverde
Sorry for being late to the party, I was on vacations.
I'd also like seeing TG2 switching to mercurial. Most of the pro arguments
have been already mentioned in this thread but I'll briefly repeat those
that I find most valuable:
- Being able to work offline. I know most of us have a good internet
connection most of the time but the fact that it allows offline use makes
many operations *way* faster (update to prev. revision, branch, view the
log, see diffs, etc...). Besides that, I find it very productive to take
my laptop to a net-free zone (trains are the best!) and get work done, for
a change :)
- Non-commiters can work on *complex* changes and then post a bundle for
review in the trac. Better still, if twWebSite is leveraged, any
registered user can create a repo/branch in tg.org to act as a "central"
repository to collaborate with others or just plainly let everyone see
what they're up to. These branches are then very easy to merge, usually
just a "hg -u pull <someurl>" away. If conflicts occur kdiff (or your
favorite merge tool) is spawned automatically to make conflict resoultion
a breeze.
- Makes sprints easier to organize for the reason above.
- hgweb can create tarballs on the fly (on-demand snapshots) from any tag,
revision or the tip. This is what http://toscawidgets.org/download uses to
provide dev snapshots to easy_install. Without any external tool (save a
short script to generates these links)
- if twWebSite is leveraged (the code that powers tw.org) tracs and
repositories can be easily created by registered (or specially authorized)
users for related projects (eg: tgext.repoze.who, tg.authorization,
tg.devtools, ...). This fits very well with TG2's philosophy of splitting
up into smaller, independently maintained, components. I know SVN can be
used for this as well but twWebsite is already written and I didn't hear
anyone volunteer to write the SVN counterpart (let alone share some code
;)
- patch queues could be a lifesaver for those in the absolute need of
working-with/deploying a patched version of TG2.
- From a personal philosophical POV: de-centralized better than
centralized: p2p, internet, federalism vs. new-world-order... ;)
To sum up, Most of the disadvantages pointed out in this thread refer to
social problems rather than technical and will need to be sorted out using
social means (how to handle multiple branches, where to pull release from,
etc...) but the point is that Hg (or any distributed VCS) allows that
freedom while centralized VCS don't, in fact, one can follow a pretty much
centralized work-flow while using a DVCS (see the current usage of tw.org
as an example) while pseudo-DVCS behavior using SVN is kludgy (to say the
least ;)
So, if this goes forward, what are the time-frames for the migration? I
need to polish up twWebSite quite a bit before it can be easily reused in
other sites.
Alberto
Florent Aide
>
> Hi,
>
> Sorry for being late to the party, I was on vacations.
>
> I'd also like seeing TG2 switching to mercurial. Most of the pro arguments
> have been already mentioned in this thread but I'll briefly repeat those
> that I find most valuable:
I'm also in favor of a change to HG in regards of all the goodies that
it may give. _But_ I would like this migration to happen after the
official 2.0 release and 1.1 release. So that we don't provoke too
much turmoil in the dev tools right now.
I've got my toolchain working on windows, macos & linux with direct
access to the net and SSH tunneled only and I'd like to have time to
ponder the options for this migration.
Florent.
Jorge Godoy
> On 9/2/08, Alberto Valverde <alb...@toscat.net> wrote:
> > Hi,
> >
> > Sorry for being late to the party, I was on vacations.
> >
> > I'd also like seeing TG2 switching to mercurial. Most of the pro
> > arguments have been already mentioned in this thread but I'll briefly
> > repeat those that I find most valuable:
>
> I'm also in favor of a change to HG in regards of all the goodies that
> it may give. _But_ I would like this migration to happen after the
> official 2.0 release and 1.1 release. So that we don't provoke too
> much turmoil in the dev tools right now.
Does anyone have a migration plan? I mean, a series of commands and
configurations that would be run to migrate our repository?
I did the change on one project here, but I had to use hgimportsvn to be able
to get everything and the initial process seemed to be really slow (this
project only had 2700 revisions).
Also, for how long will we keep a read-only SVN repository (hgpullsvn can help
keeping it up to date)? Because if we have branches and work being done on
SVN (and don't have the same "plan" that TG followed on the main repository)
we don't necessarily need / can / want to commit before the move. Having the
read-only repository would help creating patches to apply over a new checkout
using mercurial, when the "time constraint" allows the developer / company /
team / whatever to do that (i.e., if I am in the middle of a certification /
validation process I can't change the repository immediately).
I know all this sounds too corporate, but that's the kind of planning I do
everyday for a bank and for companies in the human health market...
> I've got my toolchain working on windows, macos & linux with direct
> access to the net and SSH tunneled only and I'd like to have time to
> ponder the options for this migration.
Can we get the migration done using a batch? I mean, one big script that woul
dbe run to migrate our official repository, including users and etc.? If it
is too hard, maybe part automated and part explaining how to change commands
to accomplish the whole change.
This would allow the change for personal repositories to follow the same
process in the future... (Also extremely useful to document things and for
widget authors that will want to migrate.)
--
Jorge Godoy <jgo...@gmail.com>
mark.mch...@gmail.com
> configurations that would be run to migrate our repository?
plan because I didn't want to waste time on a detailed plan if we
weren't really going to make a change.
> I did the change on one project here, but I had to use hgimportsvn to be able
> to get everything and the initial process seemed to be really slow (this
> project only had 2700 revisions).
creating a new repository. But at least it only has to be done
once. And it supports pulling just one section of the svn tree out
into it's own repository, with just the history for that "branch."
> Also, for how long will we keep a read-only SVN repository (hgpullsvn can help
> keeping it up to date)? Because if we have branches and work being done on
> SVN (and don't have the same "plan" that TG followed on the main repository)
> we don't necessarily need / can / want to commit before the move. Having the
> read-only repository would help creating patches to apply over a new checkout
> using mercurial, when the "time constraint" allows the developer / company /
> team / whatever to do that (i.e., if I am in the middle of a certification /
> validation process I can't change the repository immediately).
think it makes sense to maintain a svn repository that has reasonably
current code for several months at least. The question is how often
to merge changes over to that repository, and how fine-grained the
history of that repository needs to be. Would it be good enough to
just do a svn checkin nightly from the current mercurial tip? --
perferably only if all the tests pass. ;)
Or should we try to automate it so every changeset is pushed over
separately?
> I know all this sounds too corporate, but that's the kind of planning I do
> everyday for a bank and for companies in the human health market...
> dbe run to migrate our official repository, including users and etc.? If it
> is too hard, maybe part automated and part explaining how to change commands
> to accomplish the whole change.
bad, even if we have to do some manual bits there. It's not like we
have hundreds of active commiters.
> This would allow the change for personal repositories to follow the same
> process in the future... (Also extremely useful to document things and for
> widget authors that will want to migrate.)
people can move their TG related projects to our new hg+trac system
when they want to make that change.
--Mark
iain duncan
> I'm not 100% sure I follow you here. What is your suggestion? I
> think it makes sense to maintain a svn repository that has reasonably
> current code for several months at least. The question is how often
> to merge changes over to that repository, and how fine-grained the
> history of that repository needs to be. Would it be good enough to
> just do a svn checkin nightly from the current mercurial tip? --
> perferably only if all the tests pass. ;)
>
> Or should we try to automate it so every changeset is pushed over
> separately?
If I were the user in question, I would not find it all unreasonable to
have daily snapshots, and would probably prefer daily passing snaps.
After all, if I *need* bleeding edge, I can get it via hg and merge
myself.
> Yea, we should definitely document how the conversion is done, and how
> people can move their TG related projects to our new hg+trac system
> when they want to make that change.
A big +1 on that.
Iain
Jorge Vargas
<mark.mch...@gmail.com> wrote:
>
>> Does anyone have a migration plan? I mean, a series of commands and
>> configurations that would be run to migrate our repository?
>
> Not yet. I brought up the question before comming up with a detailed
> plan because I didn't want to waste time on a detailed plan if we
> weren't really going to make a change.
>
to give away my knowledge (maybe scripts if that's reasonable) when
TG's migration comes.
>> I did the change on one project here, but I had to use hgimportsvn to be able
>> to get everything and the initial process seemed to be really slow (this
>> project only had 2700 revisions).
>
> Yea, that is my experience too, it's pulling every changeset, and
> creating a new repository. But at least it only has to be done
> once. And it supports pulling just one section of the svn tree out
> into it's own repository, with just the history for that "branch."
>
which is one of the reason's probably making a migration script isn't
a great idea. After all it will just be several calls to hgimportsvn.
>> Also, for how long will we keep a read-only SVN repository (hgpullsvn can help
>> keeping it up to date)? Because if we have branches and work being done on
>> SVN (and don't have the same "plan" that TG followed on the main repository)
>> we don't necessarily need / can / want to commit before the move. Having the
>> read-only repository would help creating patches to apply over a new checkout
>> using mercurial, when the "time constraint" allows the developer / company /
>> team / whatever to do that (i.e., if I am in the middle of a certification /
>> validation process I can't change the repository immediately).
>
> I'm not 100% sure I follow you here. What is your suggestion? I
> think it makes sense to maintain a svn repository that has reasonably
> current code for several months at least. The question is how often
> to merge changes over to that repository, and how fine-grained the
> history of that repository needs to be. Would it be good enough to
> just do a svn checkin nightly from the current mercurial tip? --
> perferably only if all the tests pass. ;)
>
I'm not sure if this is a good idea. I'll prefer a band-aid approach
(quick so it won't hurt) having two versioning systems wil just
confuse people.
Which branches are you talking about? private-local branches? Since
both systems understand patch really well, migration shouldn't be an
issue, running svn diff, and then patch on the mercurial checkout
should be a problem. The only case where this should break is if you
have moved files and that will be an issue just if you moved a lot of
files.
> Or should we try to automate it so every changeset is pushed over
> separately?
>
>> I know all this sounds too corporate, but that's the kind of planning I do
>> everyday for a bank and for companies in the human health market...
>
>> Can we get the migration done using a batch? I mean, one big script that woul
>> dbe run to migrate our official repository, including users and etc.? If it
>> is too hard, maybe part automated and part explaining how to change commands
>> to accomplish the whole change.
>
> Well the user bit would be the hardest, and I don't think it's too
> bad, even if we have to do some manual bits there. It's not like we
> have hundreds of active commiters.
>
I don't really know how the current svn/trac users are manage, but
mercurial uses the same approach as svn. So it's probably just an
issue of moving the current names into the new db.
>> This would allow the change for personal repositories to follow the same
>> process in the future... (Also extremely useful to document things and for
>> widget authors that will want to migrate.)
>
> Yea, we should definitely document how the conversion is done, and how
> people can move their TG related projects to our new hg+trac system
> when they want to make that change.
>
In my opinion the hard part will be trac, as the migration will
probably have to export all data, and then into the new trac
environment. The hardest part will be to determine what "all data" is
for each project.
> --Mark
> >
>
Lukasz Szybalski
in this thread?
http://bazaar-vcs.org/BzrPlugins
Thanks,
Lucas
Lukasz Szybalski
> Just out of curiosity, is there a reason why bazaar is not mentioned
> in this thread?
>
> http://bazaar-vcs.org/BzrPlugins
Actually an interesting comparison here:
http://www.infoq.com/articles/dvcs-guide
Lucas
Florent Aide
>
> Just out of curiosity, is there a reason why bazaar is not mentioned
> in this thread?
>
> http://bazaar-vcs.org/BzrPlugins
Certainly because none of the people who mentionned interest in this
thread wanted to implement a bazaar bazed solution... And because this
discussion originated from the statement that we could host alberto's
things (toscawigets & al) and also profit from his already integrated
architecture based on trac and mercurial.
Florent.
Lukasz Szybalski
I see.
Actually I just created a project on launchpad and started using
bazaar and it goes pretty well.
Not sure if you guys knew this but Loggerhead
(https://launchpad.net/loggerhead) which is a web viewer for projects
in bazaar that can be used to navigate a branch history, annotate
files, view patches, perform searches, and is used by launchpad was
initially based on tubogears !!
In a more recent version I think they switched to a pythonpaste and
from kid to zpt.
Lucas
Gustavo Narea
> > Certainly because none of the people who mentionned interest in this
> > thread wanted to implement a bazaar bazed solution... And because this
> > discussion originated from the statement that we could host alberto's
> > things (toscawigets & al) and also profit from his already integrated
> > architecture based on trac and mercurial.
>
> I see.
>
> Actually I just created a project on launchpad and started using
> bazaar and it goes pretty well.
Yes, I also think it's a good idea, but I think it's not going to happen:
http://groups.google.com/group/turbogears-trunk/browse_thread/thread/cc89f66dc8e59d43
--
Gustavo Narea.
http://gustavonarea.net/
Get rid of unethical constraints! Switch to Freedomware:
http://softwareliberty.com/
Jorge Vargas
>
> On Thursday October 16, 2008 05:31:59 Lukasz Szybalski wrote:
>> > Certainly because none of the people who mentionned interest in this
>> > thread wanted to implement a bazaar bazed solution... And because this
>> > discussion originated from the statement that we could host alberto's
>> > things (toscawigets & al) and also profit from his already integrated
>> > architecture based on trac and mercurial.
>>
>> I see.
>>
>> Actually I just created a project on launchpad and started using
>> bazaar and it goes pretty well.
>
> Yes, I also think it's a good idea, but I think it's not going to happen:
> http://groups.google.com/group/turbogears-trunk/browse_thread/thread/cc89f66dc8e59d43
> --
reply but time just passed by and I forgot :(
The mian reasoning goes this way:
- what does bazaar provides that mercurial doesn't?
- is there trac integration? mercurial-trac is awesome and very stable
and well tests.
- bazaar != launchpad, most people "love" bazaar when they really love
launchpad, using launchpad for TG is not a great idea as we have a ton
of things running that aren't issue tracker + repository, to name a
flew the docs, the widget browser (a tg1 app), the geo sample (not
sure if they are running from the same box), the buildbot, so in
conclusion we have a lot of things, that need to run on TG server so
in the long run it's better to have everything centralized
- TG is actually a big set of projects, and it's going to become more
not less. Which means that even though they are separate we need to
keep the flag of "group of projects" as far as i know this isn't
possible with bazaar.
- I have been working with the twsite code and it provides auth across
mercurial/tg/trac and it also provide over-the-web creation of repos
from authorized users, so it works like our own private launchpad, or
gibhub, or whatever.
- there is a tendency of python projects to use mercurial as a dvcs.
We'll have better integration with them, for example when we need to
run of pylons tip (like now with tg2)
Lukasz Szybalski
>
> On Thu, Oct 16, 2008 at 1:19 AM, Gustavo Narea <m...@gustavonarea.net> wrote:
>>
>> On Thursday October 16, 2008 05:31:59 Lukasz Szybalski wrote:
>>> > Certainly because none of the people who mentionned interest in this
>>> > thread wanted to implement a bazaar bazed solution... And because this
>>> > discussion originated from the statement that we could host alberto's
>>> > things (toscawigets & al) and also profit from his already integrated
>>> > architecture based on trac and mercurial.
>>>
>>> I see.
>>>
>>> Actually I just created a project on launchpad and started using
>>> bazaar and it goes pretty well.
>>
>> Yes, I also think it's a good idea, but I think it's not going to happen:
>> http://groups.google.com/group/turbogears-trunk/browse_thread/thread/cc89f66dc8e59d43
>> --
> Sorry for not replying to that thread I was going to write a long
> reply but time just passed by and I forgot :(
>
It would be best if mercurial and bazaar merged together into one project!!
> The mian reasoning goes this way:
> - what does bazaar provides that mercurial doesn't?
1. The ability to version and rename directories is something neither
Git nor Mercurial have.
2. Bazaar plugin for svn can at the moment be used to commit to, pull
from, merge from, push to and view logs of Subversion branches from
Bazaar.
What mercurial provides that bazaar doesn't?
> - is there trac integration?
Yes there is a bazaar plugin for trac.
> - bazaar != launchpad, most people "love" bazaar when they really love
> launchpad, using launchpad for TG is not a great idea as we have a ton
> of things running that aren't issue tracker + repository, to name a
> flew the docs, the widget browser (a tg1 app), the geo sample (not
> sure if they are running from the same box), the buildbot, so in
> conclusion we have a lot of things, that need to run on TG server so
> in the long run it's better to have everything centralized
Since you are going with distributed system, this means that the whole
TG project will be even more decentralized then it is now. I suspect
we will have more branches of tg2 each with various patches. So svn
kind of keeps it in one place at the moment.
> - TG is actually a big set of projects, and it's going to become more
> not less. Which means that even though they are separate we need to
> keep the flag of "group of projects" as far as i know this isn't
> possible with bazaar.
Not sure what you mean here.
> - I have been working with the twsite code and it provides auth across
> mercurial/tg/trac and it also provide over-the-web creation of repos
> from authorized users, so it works like our own private launchpad, or
> gibhub, or whatever.
I'm sure you could setup similar authentication with bazaar.
> - there is a tendency of python projects to use mercurial as a dvcs.
> We'll have better integration with them, for example when we need to
> run of pylons tip (like now with tg2)
Not sure how turbogears2 and pylons branching is done.
Based on the svn plugin for bazaar, if somebody wanted to use bazaar
they could do it with svn server that is in place. They get all the
distributed merging and branching while everybody else gets the svn.
Lucas
Jorge Vargas
>
> On Thu, Oct 16, 2008 at 12:04 PM, Jorge Vargas <jorge....@gmail.com> wrote:
>>
>> On Thu, Oct 16, 2008 at 1:19 AM, Gustavo Narea <m...@gustavonarea.net> wrote:
>>>
>>> On Thursday October 16, 2008 05:31:59 Lukasz Szybalski wrote:
>>>> > Certainly because none of the people who mentionned interest in this
>>>> > thread wanted to implement a bazaar bazed solution... And because this
>>>> > discussion originated from the statement that we could host alberto's
>>>> > things (toscawigets & al) and also profit from his already integrated
>>>> > architecture based on trac and mercurial.
>>>>
>>>> I see.
>>>>
>>>> Actually I just created a project on launchpad and started using
>>>> bazaar and it goes pretty well.
>>>
>>> Yes, I also think it's a good idea, but I think it's not going to happen:
>>> http://groups.google.com/group/turbogears-trunk/browse_thread/thread/cc89f66dc8e59d43
>>> --
>> Sorry for not replying to that thread I was going to write a long
>> reply but time just passed by and I forgot :(
>>
>
> It would be best if mercurial and bazaar merged together into one project!!
>
>> The mian reasoning goes this way:
>> - what does bazaar provides that mercurial doesn't?
>
> 1. The ability to version and rename directories is something neither
> Git nor Mercurial have.
actually that is a design decision as far as I know the only problem
they have is that you can't version empty directories which is useful
but not critical.
> 2. Bazaar plugin for svn can at the moment be used to commit to, pull
> from, merge from, push to and view logs of Subversion branches from
> Bazaar.
>
umm that's a big plus, mercurial's is a bit behind because you can't
commit directly. although hgsvnimport is very good. Now I see it as a
no-go for tg as we'll be moving everything.
> What mercurial provides that bazaar doesn't?
>
>> - is there trac integration?
>
> Yes there is a bazaar plugin for trac.
>
oh I didn't knew about it, is it stable? feature complete?
trac-mercurial is almost done
only 3 mayor differences
http://trac.edgewall.org/wiki/TracMercurial#FeaturesthatTracsvnhasbutnotcurrentlyimplementedforTrachg
>> - bazaar != launchpad, most people "love" bazaar when they really love
>> launchpad, using launchpad for TG is not a great idea as we have a ton
>> of things running that aren't issue tracker + repository, to name a
>> flew the docs, the widget browser (a tg1 app), the geo sample (not
>> sure if they are running from the same box), the buildbot, so in
>> conclusion we have a lot of things, that need to run on TG server so
>> in the long run it's better to have everything centralized
>
> Since you are going with distributed system, this means that the whole
> TG project will be even more decentralized then it is now. I suspect
> we will have more branches of tg2 each with various patches. So svn
> kind of keeps it in one place at the moment.
you missed the point, by centralized I was referring to all the
official copies on the same machine. instead of having to admin the
launchpad stuff and the tg stuff.
>
>> - TG is actually a big set of projects, and it's going to become more
>> not less. Which means that even though they are separate we need to
>> keep the flag of "group of projects" as far as i know this isn't
>> possible with bazaar.
>
> Not sure what you mean here.
>
take a look at www.toscawidgets.org each project is in it's own repo
and some have trac instances, but they all belong to toscawidgets. So
if you go for example here:
you will get all official TW packages http://toscawidgets.org/hg
>> - I have been working with the twsite code and it provides auth across
>> mercurial/tg/trac and it also provide over-the-web creation of repos
>> from authorized users, so it works like our own private launchpad, or
>> gibhub, or whatever.
>
> I'm sure you could setup similar authentication with bazaar.
>
two things
1- you could, as opposed to it is already done
2- integration isn't that trivial, the current code creates
repositories from the webinterface, does bazaar provides a wsgi
server?, can I manage it's users from wsgi?
>> - there is a tendency of python projects to use mercurial as a dvcs.
>> We'll have better integration with them, for example when we need to
>> run of pylons tip (like now with tg2)
>
> Not sure how turbogears2 and pylons branching is done.
>
there isn't branching they are totally different projects. you
normally install TG and pylons. from trunk/tip.
but when you are working on both projects it's very annoying to type
svn status inside the pylons code, and vice versa.
Also some people could take advantage of things like the forest extension.
>
> Based on the svn plugin for bazaar, if somebody wanted to use bazaar
> they could do it with svn server that is in place. They get all the
> distributed merging and branching while everybody else gets the svn.
>
This has been discusses a in the thread, the goal is not to provide
easy dvcs for individual developers, you could do that with svk, git,
mercurial, bazaar, whatever. The goal is to migrate the main server to
distributed.
Now I got a question, the only advantage you outlined is the svn
integration which we don't need. And all the disadvantages are still
in place, the most important one being that we have code running to
integrate hg, while there isn't any for bazaar. So I ask again what
are the advantages for TG core to be in bazaar?
> Lucas
>
> >
>