Experimental migration from Subversion to Mercurial
0 views
Skip to first unread message
Matthew Scott
Jan 12, 2008, 3:26:16 AM1/12/08
to Schevo
Hi folks,
After reading more about distributed version control systems (DVCSs),
and reflecting on some of the usage patterns of the Subversion
repository in the past, I have become convinced that it would be great
to migrate the Schevo projects' repositories from Subversion to
Mercurial.
The domain I just registered, "getschevo.org", isn't ready yet, but
the experimental repositories are. Note: that says
"experimental". :) That means that the move isn't final, and the
whole thing is up for comments, questions, improvements (such as
better setuptools integration), etc.
See http://getschevo.org/hg/repos.cgi/ for all of the experimental
repositories, including the script that assisted with the migration.
Resources:
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
For the TortoiseSVN lovers:
http://tortoisehg.sf.net/
--
Matthew R. Scott
After reading more about distributed version control systems (DVCSs),
and reflecting on some of the usage patterns of the Subversion
repository in the past, I have become convinced that it would be great
to migrate the Schevo projects' repositories from Subversion to
Mercurial.
The domain I just registered, "getschevo.org", isn't ready yet, but
the experimental repositories are. Note: that says
"experimental". :) That means that the move isn't final, and the
whole thing is up for comments, questions, improvements (such as
better setuptools integration), etc.
See http://getschevo.org/hg/repos.cgi/ for all of the experimental
repositories, including the script that assisted with the migration.
Resources:
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
For the TortoiseSVN lovers:
http://tortoisehg.sf.net/
--
Matthew R. Scott
Matthew Scott
Jan 17, 2008, 1:05:26 PM1/17/08
to Schevo
Here is some more information about why I am proposing we move to
Mercurial.
Active readers: I intend to continue refining the Mercurial
experience for Schevo, and intend to steer the project in that
direction rather quickly. :) Please respond with a "+1", "neutral",
or "-1 (and here's why)" if you have a few moments after reading this.
My lazy comparison of Subversion-style repositories and DVCS
repositories:
1. In Subversion, branching and merging are implemented as conceptual
layers atop of a core that basically provides an efficient versioned
filesystem.
2. In DVCS, a versioned filesystem is implemented as a conceptual
layer atop of a core that basically provides an efficient branching
and merging mechanism.
Between "efficient versioned filesystem" and "efficient branching and
merging", I think I'd pick the latter.
Our experience with Subversion within the Schevo project has brought
us a few problems. To summarize:
* In a hurry, some changes get pushed into trunk without getting
vetted through a branch first. Sometimes those changes cause
unexpected problems that could be caught during a review. Branches
are painful to create with Subversion and need network access (which
is at times not available when it would certainly be convenient for it
to be!), so sometimes you just need to edit trunk, get the product out
the door, and commit to trunk to at least have a backup in the
Subversion repository.
* I'll be blunt about this one: there was chaos a couple of years ago
due to a contributor wanting to make massive changes to trunk and who
refused to go through a branching process. Subversion didn't gain any
political kudos here, and I know Schevo is not the only project (and
that contributor is not the only person) to have had similar
incidents.
DVCS can help avoid these problems:
* In a hurry, make a quick clone of your repository (it's just a
directory on your disk) and make your change there. Commit it right
away so you have version history. Get your product out the door.
When you have network access, bundle up your changes and post them to
a mailing list, attach them to a ticket, or go through whatever other
vetting process the project desires. After it's vetted, someone
merges it into an "official" repository (since most projects have
those). You can then pull from that official repository into the
clone you made at the beginning of the process, and update it to have
the updated version of your original change.
* Any exuberant contributor is free to make any changes they want!
And the user who prefers a more stable progression can peacefully
coexist. This is because anyone can easily create and host their own
repository, and it's relatively easy to change the workflow that one
uses to move patchsets around. One idea I received was to have dual
repositories for each project: an official "vetted" repository, and
an open "catchall" repository (since within a repository you can have
many independent branches and merges). A vetting process would exist
to cherry-pick from the well-tested, well-reviewed branches of the
open repository and merge them into the official repository.
The main problem with DVCS is that while there are many good
implementations of very good ideas, how do you choose which one to
use? Do you choose by user base? Feature set? Speed? Platform
compatibility? Brand marketing?
I ended up choosing Mercurial because of a few reasons:
1. Pylons uses it, and I like to keep track of what that project is
doing, so Mercurial became the first DVCS tool that I used regularly
to pull changes, rather than just 'trying it out" as with my
experiments with bzr and git.
2. Others have given me anecdotes of their usage of Mercurial and I
hear it's a workhorse, able to handle large repositories well.
3. When I began using Mercurial for a small project, I found it easy
to push and pull changes between systems, and easy to publish using
Mercurial's built-in web interface.
On Jan 12, 12:26 am, Matthew Scott <gldns...@gmail.com> wrote:
> Hi folks,
>
> After reading more about distributed version control systems (DVCSs),
> and reflecting on some of the usage patterns of the Subversion
> repository in the past, I have become convinced that it would be great
> to migrate the Schevo projects' repositories from Subversion to
> Mercurial.
>
> The domain I just registered, "getschevo.org", isn't ready yet, but
> the experimental repositories are. Note: that says
> "experimental". :) That means that the move isn't final, and the
> whole thing is up for comments, questions, improvements (such as
> better setuptools integration), etc.
>
> Seehttp://getschevo.org/hg/repos.cgi/for all of the experimental
Mercurial.
Active readers: I intend to continue refining the Mercurial
experience for Schevo, and intend to steer the project in that
direction rather quickly. :) Please respond with a "+1", "neutral",
or "-1 (and here's why)" if you have a few moments after reading this.
My lazy comparison of Subversion-style repositories and DVCS
repositories:
1. In Subversion, branching and merging are implemented as conceptual
layers atop of a core that basically provides an efficient versioned
filesystem.
2. In DVCS, a versioned filesystem is implemented as a conceptual
layer atop of a core that basically provides an efficient branching
and merging mechanism.
Between "efficient versioned filesystem" and "efficient branching and
merging", I think I'd pick the latter.
Our experience with Subversion within the Schevo project has brought
us a few problems. To summarize:
* In a hurry, some changes get pushed into trunk without getting
vetted through a branch first. Sometimes those changes cause
unexpected problems that could be caught during a review. Branches
are painful to create with Subversion and need network access (which
is at times not available when it would certainly be convenient for it
to be!), so sometimes you just need to edit trunk, get the product out
the door, and commit to trunk to at least have a backup in the
Subversion repository.
* I'll be blunt about this one: there was chaos a couple of years ago
due to a contributor wanting to make massive changes to trunk and who
refused to go through a branching process. Subversion didn't gain any
political kudos here, and I know Schevo is not the only project (and
that contributor is not the only person) to have had similar
incidents.
DVCS can help avoid these problems:
* In a hurry, make a quick clone of your repository (it's just a
directory on your disk) and make your change there. Commit it right
away so you have version history. Get your product out the door.
When you have network access, bundle up your changes and post them to
a mailing list, attach them to a ticket, or go through whatever other
vetting process the project desires. After it's vetted, someone
merges it into an "official" repository (since most projects have
those). You can then pull from that official repository into the
clone you made at the beginning of the process, and update it to have
the updated version of your original change.
* Any exuberant contributor is free to make any changes they want!
And the user who prefers a more stable progression can peacefully
coexist. This is because anyone can easily create and host their own
repository, and it's relatively easy to change the workflow that one
uses to move patchsets around. One idea I received was to have dual
repositories for each project: an official "vetted" repository, and
an open "catchall" repository (since within a repository you can have
many independent branches and merges). A vetting process would exist
to cherry-pick from the well-tested, well-reviewed branches of the
open repository and merge them into the official repository.
The main problem with DVCS is that while there are many good
implementations of very good ideas, how do you choose which one to
use? Do you choose by user base? Feature set? Speed? Platform
compatibility? Brand marketing?
I ended up choosing Mercurial because of a few reasons:
1. Pylons uses it, and I like to keep track of what that project is
doing, so Mercurial became the first DVCS tool that I used regularly
to pull changes, rather than just 'trying it out" as with my
experiments with bzr and git.
2. Others have given me anecdotes of their usage of Mercurial and I
hear it's a workhorse, able to handle large repositories well.
3. When I began using Mercurial for a small project, I found it easy
to push and pull changes between systems, and easy to publish using
Mercurial's built-in web interface.
On Jan 12, 12:26 am, Matthew Scott <gldns...@gmail.com> wrote:
> Hi folks,
>
> After reading more about distributed version control systems (DVCSs),
> and reflecting on some of the usage patterns of the Subversion
> repository in the past, I have become convinced that it would be great
> to migrate the Schevo projects' repositories from Subversion to
> Mercurial.
>
> The domain I just registered, "getschevo.org", isn't ready yet, but
> the experimental repositories are. Note: that says
> "experimental". :) That means that the move isn't final, and the
> whole thing is up for comments, questions, improvements (such as
> better setuptools integration), etc.
>
> repositories, including the script that assisted with the migration.
>
> Resources:http://betterexplained.com/articles/intro-to-distributed-version-cont...
>
keios...@gmail.com
Jan 17, 2008, 1:43:55 PM1/17/08
to Schevo
One quick question, can a Mercurial repository be migrated to Git?
Here is something I read - http://www.simplicidade.org/notes/archives/2007/12/git_vs_mercuria_1.html
> > Seehttp://getschevo.org/hg/repos.cgi/forall of the experimental
Here is something I read - http://www.simplicidade.org/notes/archives/2007/12/git_vs_mercuria_1.html
Matthew Scott
Jan 17, 2008, 5:18:46 PM1/17/08
to Schevo
On Jan 17, 10:43 am, "keios.ti...@gmail.com" <keios.ti...@gmail.com>
wrote:
> One quick question, can a Mercurial repository be migrated to Git?
> Here is something I read -http://www.simplicidade.org/notes/archives/2007/12/git_vs_mercuria_1....
>
Thanks for the link.
It's not too late to try Git instead of Mercurial -- no one has made
any commits to the Mercurial repositories yet.
One reason I hadn't considered Git was because I was ignorant of its
recent Windows support.
I'll see how easy it is to handle the "install from an EXE" snapshots
of Git for Windows, and create a script to convert the Schevo
repository to git much like I wrote one to convert to svn.
I'd rather pick one over the other and then stick with it. CVS to
Subversion was not a bad conversion a few years ago, because they
aren't that much different. But the DVCS landscape is varied enough
that I don't want to spend too much "meta" time away from actual
Schevo hacking. :)
Matthew Scott
Jan 17, 2008, 11:27:36 PM1/17/08
to Schevo
On Jan 17, 2:18 pm, Matthew Scott <gldns...@gmail.com> wrote:
> On Jan 17, 10:43 am, "keios.ti...@gmail.com" <keios.ti...@gmail.com>
> wrote:
>
> > One quick question, can a Mercurial repository be migrated to Git?
> > Here is something I read -http://www.simplicidade.org/notes/archives/2007/12/git_vs_mercuria_1....
>
> Thanks for the link.
>
> It's not too late to try Git instead of Mercurial -- no one has made
> any commits to the Mercurial repositories yet.
against both, in favor of Mercurial:
1. git's web service has complicated setup instructions that involved
passing options to a Makefile; Mercurial's was easy to drop in to a
Webfaction static/cgi/php app container with about three lines of file
editing.
2. bzr didn't have a built-in Subversion import feature (git and
Mercurial packages both do), and the bzr-svn plugin doesn't support
importing from subtrees within a repository. Mercurial imported
everything swiftly and sanely.
All of them probably lag as far as GUI tool support for Windows, but
Mercurial has TortoiseHG going for it, which helps for Windows
developers that are accustomed to using TortoiseSVN :-)
Plus, I read this:
http://www.dribin.org/dave/blog/archives/2007/12/30/why_mercurial/
I think we'll go ahead and stick with the Mercurial setup for now. If
the overall experience with git and bzr improves, then we can take a
look at using them in the future. I'm more anxious to get some code-
writing done, so I'm done with the DVCS analysis for now :)
keios...@gmail.com
Jan 18, 2008, 1:07:32 PM1/18/08
to Schevo
Cool, thanks for the information.
Reply all
Reply to author
Forward
0 new messages