[Opensim-dev] Status of presence refactor?

Mon Feb 22 22:41:09 UTC 2010

*> we're all still fairly ignorant when it comes to using git, and *
*> we've all had close encounters with git disasters.*

Why are we using GIT?  I understand that it's supposed to be better than
CVS/SVN, but it's still a dinosaur compared to Mercurial or Bazaar.  Why
aren't we using Mercurial?

*> Melanie is the one keeping branches in sync, she has spent *
*> a lot of time resolving conflicts by hand, helping out the *
*> messes we get into, etc. *

That seems extremely insane, and that's the whole problem with Git. It would
make more sense to use something like Mercurial.  Much easier with the
"intelligent syncing" feature of Mercurial (which Git doesn't have, so
everything must be done manually with Git and wastes a lot of time).

*> She can do that with one branch but not with many... *

It would really make much more sense to switch over to Mercurial (or Bazaar)
for the development work.

Mercurial (and Bazaar) are even faster than Git, plus Mercurial has the best
"intelligent merging" and allows users to work only on one directory of the
repository (to help limit damage, etc.).  The "Intelligent Merging" features
are nice (make commits easy on the dev's).

Lots of great features in Mercurial, and it's probably by far the best (or
at least much better than CVS, Subversion, or Git).  Bazaar and Mercurial
are probably the two best.

http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html

I could setup a Mercurial or Bazaar repository on a server (for redundancy
purposes) and then each of the Dev's can just use Mercurial on their desktop
to collaborate peer to peer (and I can perform backups of the main Mercurial
server, just so we have backup, snapshot and restore points).  It will help
with the "intelligent merging" (for numerous dev's all working together all
at the same time) and we can always feed copies of the Merc repository back
to the old Git and just use the old Git repository as a public archive.

Mercurial is extremely easy to use:

http://hgbook.red-bean.com/read/mercurial-in-daily-use.html#id496680

Merc is peer to peer, and supports backups/mirroring, and has lots of great
features.  I can just setup a master server (with a cron job) to
automatically pull periodic changes from your local repositories every hour
(for all the core dev's).  Since Mercurial maintains a complete copy of
history in each clone (every single peer), everyone who uses Mercurial to
collaborate on a project can potentially act as a source of "backups" in the
event of a "catastrophe" (since there is no real "centralized" server).  If
a central repository becomes unavailable, you simply just clone a copy of
the repository from one contributer, and pull any changes they may not have
seen from all the other contributers.

Mercurial is extremely easy to perform off-site backups and remote mirrors.
 Plus I can set it up to perform traditional backups to tape or disk (for
archival purposes).  This way if there are any problems, we can always roll
back, or undo or perform disaster recovery.

To do backups, you just use "hg clone -U myrepo myrepo.bak" to create a
clone of the "myrepo" repository and then just perform a nightly backup,
that way automated nightly backups are being performed on the repository.

This way you have something to roll back to, even if disaster does strike (a
dev somehow hoses everything up, which is unlikely) but regardless it never
hurts to have backups and consistent snapshots.

Mercurial maintains a complete copy of history in each clone, so it creates
numerous "backups" (and lots of redundancy).  By having a dedicated server
online, that will just act as a "main peer" at least all the other peers can
feed/seed back to the main peer anytime they are online or connected to the
internet.  The main server will simply act as a "seed", and all the other
dev's computers (that may go on or offline) will simply act as peers for
redundancy purposes.  It's almost similar to a "torrent" type of
architecture (P2P) which is good for speed of uploading/committing large
updates since it can pull from any of the available online peers that are
online.  (Very similar to torrent).  I could maintain a "seed" server, and
just perform nightly backups onto a 2TB drive, and that way we could easily
have 6 months, or even a year or two of nightly backups for
disaster/archival purposes just in case any "accidents" do happen.

                 Mark

On Mon, Feb 22, 2010 at 4:01 PM, Cristina Videira Lopes
<lopes at ics.uci.edu>wrote:

> Yeah, we could have done that in theory. In practice, we're all still
> fairly ignorant when it comes to using git, and we've all had close
> encounters with git disasters. Melanie is the one keeping branches in
> sync, she has spent a lot of time resolving conflicts by hand, helping
> out the messes we get into, etc. She can do that with one branch but
> not with many... so until several of us learn how to deal with git
> errors effectively, it's not wise to multiply branches. We'll learn as
> we go, and hopefully we'll get better at using git.
>
>
> On Feb 22, 2010, at 11:47 AM, Toni Alatalo wrote:
>
> > diva at metaverseink.com kirjoitti:
> >> We can, by this order:
> >> 1) merge presence-refactor into master
> >> 2) create a sop-refactor branch from master immediately after
> >> 3) create a 0.7 branch some time later
> >> I would like to propose that the sop refactoring work be done in a
> >> branch rather than in the master branch, similar to what we did for
> >> the
> >>
> >
> > I also think a branch for it is a good idea, but don't know why wait -
> > the sop-refactor branch can also be branched from presence-refactor
> > right now if Adam wants to start already. Like Melanie suggested some
> > days ago in this thread.
> >
> > AFAIK this won't be a problem with git, 'cause commits are commits and
> > it doesn't matter from which repo they are from, a version being a set
> > of commits. So sop-refactor could first pull from presence-refactor if
> > work still goes on there, and then keep pulling from master when it
> > lives there, etc.
> >
> > Perhaps this is not relevant anymore if 1) can be done now, might have
> > been a good idea a couple of weeks ago when presence-refactor was
> > pretty
> > much done for parts that touch the scene(?). Also, I'm by no means a
> > git
> > expert, so am curious to know if have misunderstood it somehow and
> > this
> > idea wouldn't work .. Melanie did say in her post that it would.
> >
> > ~Toni
> >
> >
> >
> >> services refactoring. It works pretty well -- gives the refactoring
> >> devs
> >> peace of mind to leave things unstable and isolates the master branch
> >> from prolonged instability.
> >>
> >> Also, are there any suggestions for Adam before he starts doing
> >> this? He
> >> sent out a document some time ago, but there wasn't a lot of
> >> feedback or
> >> discussion. Are there any alternatives or wishes for his proposed
> >> work?
> >>
> >> Justin Clark-Casey wrote:
> >>
> >>> Frisby, Adam wrote:
> >>>
> >>>> I would like to start the SOP refactor fairly soon - what if once
> >>>> 0.7 is tagged for the RC process; I go and and make a new branch;
> >>>> we can sic testers on the presence-branch, while dev happens on
> >>>> the branch I tag?
> >>>>
> >>> My concern with branching for 0.7 release candidates immediately
> >>> after the presence-refactor merge is that we won't get everybody
> >>> helping to iron out the inevitable hiccups since most people
> >>> follow master.  Waiting a couple of weeks for at least some of
> >>> this to happen is the minimum, I feel.  Ideally, I'd like that to
> >>> be longer but I know that you and other folk want to press ahead.
> >>>
> >>> I guess some of this depends on how disruptive the refactor is.
> >>> What do you think?  I'm assuming there will be breakage but
> >>> perhaps I'm wrong?
> >>>
> >>> Of course, I guess you could create a separate sop-refactor branch
> >>> at any point and start work there, possibly merging back to master
> >>> and continuing in master once 0.7 RC has been branched.
> >>>
> >>>
> >> _______________________________________________
> >> Opensim-dev mailing list
> >> Opensim-dev at lists.berlios.de
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20100222/c0ae5d11/attachment-0001.html>