Re: Version Control Repository on a “Cloud”

Giovanni Gherdovich g.gherdovich at gmail.com
Mon Nov 11 12:39:57 CST 2013


Hello Pietro,

> How can it be that a Project under Version Control,
> when on the web, requires a special, dedicated repository,
> instead of a bit of normal room into a usual Cloud directory?

It does not, actually.

A version controlled project it's just a bunch of files
and metadata (information about the files).
As such, it can be hosted anywhere you have some disk space.

You can adopt this workflow:

(alice)   <----->   (shared space)   <----->   (Bob)

Alice and Bob have Mercurial installed in their machine.
Alice does some work, and commit locally.
Then she moves the whole directory with the project
"up in the cloud", where Bob can download it.
Bob gets it on his local disk, and uses his local
Mercurial instance to see what Alice has done,
and to synchronize with his local repository.
Since Bob has been working on his own while Alice made his edit,
Bob might have to merge Alice's work into his,
and will ask his local Mercurial to do that.

This workflow is a bit of a hassle (pack repository,
upload to share space, download repository, ...)
but is very cheap since you don't have to ask your
cloud provider to install any "mercurial server" whatsoever.
Well, bitbucket.org is free, but anyways.

> For what I've seen so far (I've planned a Mercurial thorough exploration
next year)
> only specialized providers can host a Mercurial Repository

So why is "mercurial hosting" different from "file sharing"?

Because some services, like bitbucket.org or rhodecode.com,
are "aware" that the files they host are mercurial repositories,
and offer the comfort of implementing the "push" and "pull"
commands directly on their server, instead of you having
to pack-upload-download-unpack and run the commands locally.

The basic commands of a distributed version control system are

* commit (save changes so that they can be restored)
* update <revision> (go back and forth in the history)
* pull (send changes to other repository)
* push (get changes from other repository)
* merge (handle edits by multiple authors on the same file)

A "dedicated mercurial hosting" implements nothing more than
"push" and "pull", so that your local repo and the remote repo
can talk to each other using the mercurial application protocol, and not
just bare HTTP.
But again, it's just for the comfort.

There was this stackov post about using git and dropbox:
http://stackoverflow.com/questions/1960799/using-git-and-dropbox-together-effectively

I am pretty sure you can get ideas from there and apply it
to Mercurial and your file sharing service.

Regards,
GGhh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20131111/6fd1050b/attachment.html>


More information about the Mercurial mailing list