[Opensim-dev] Status of presence refactor?

Mon Feb 22 23:15:22 UTC 2010

I don't think we can survive another move. Also, I don't want to
learn another toolchain, I want to develop.

-1

Melanie

Mark Malewski wrote:
> *> 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
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev