[Opensim-dev] Status of presence refactor?
Cristina Videira Lopes
lopes at ics.uci.edu
Tue Feb 23 01:24:10 UTC 2010
Let's bring the focus of this thread back. We're about to merge the
presence-refactor branch into the master branch, and then we'll need
testers, some of us will be working overtime to fix the bugs, and
hopefully Fly-Man- will update Wiredux sometime soon. Then a big
effort in documentation will start.
There's a lot of work to do. The last thing we need is switching
development tools.
On Feb 22, 2010, at 4:58 PM, Mark Malewski wrote:
>
> > I don't think we can survive another move. Also, I don't want to
> > learn another toolchain, I want to develop.
>
> I know, but as an engineer (hardware/server/network administrator)
> it's my job to help SUPPORT you, by creating a nice environment for
> you to do your work. ;-)
>
> If you can spend 3 minutes reading this simple (and easy to use)
> tutorial for TortoiseHG (or if you've ever used TortoiseSVN), then
> you can easily use Mercurial:
>
> http://draketo.de/light/english/mercurial/short-introduction-mercurial-tortoisehg
>
> It usually takes less than 3 minutes for a developer to figure out
> how to right click, and how to click "Synchronize" or "Create
> clone". You don't need to learn or memorize any commands, just use
> TortoiseHG. It's automatically embedded into Windows File Explorer
> (or Linux) so all you have to do is right click on a folder or file
> and you can rename, update, synchronize, commit or do whatever you
> want with just one simple click.
>
> Intelligent Synchronization really does make life easier for
> developers on large collaboration projects.
>
> We don't have to do an "immediate" transition to Mercurial, but I
> can setup both Git and Mercurial (concurrently) and then we can
> slowly move users over to Mercurial (once they feel comfortable) and
> I can create a nice online tutorial for the dev's that are
> unfamiliar with Merc, and also provide links and a tutorial for
> TortoiseHG (just so dev's can see how extremely easy it is, and it
> really requires NO learning at all).
>
> You just right click on a file, or right click on a folder, and then
> select "merge" and that's it. The easy-to-use GUI really makes life
> EXTREMELY simple on the dev's. I think Mercurial is much better
> than Git for mobile users, and a project like OpenSim.
>
> I can handle the backend work (server admin, backups, etc.).
>
> This way the dev's can just focus on developing (and writing code).
> I can run both a Git and a Mercurial on the same box, that way it
> doesn't even matter what the dev's are using, both will point
> towards the same folders on the server. This way as dev's slowly
> move (and transition) from Git over to Mercurial, it will make life
> easy on them.
>
> Once you start using Mercurial, I really do think you'll love it
> (and will wonder how you ever did without it). Mercurial has the
> nice user GUI from TortoiseSVN (TortoiseHG for both Windows and
> Linux) but has the speed and advanced tools (intelligent merging/
> synchronization) of Mercurial/Bazaar.
>
> This way we can have plenty of branches, and it takes the headache
> of maintaining/doing manual conflicts (merges) out of the question.
> This way you can spend your time developing, and not dealing with
> the headaches of merging/conflicts.
>
> I can help with the implementation (and setting up a repository
> server, that will handle both Git and Mercurial, and I supposed I
> could even setup a Bazaar server as well if anyone really wants/
> needs Bazaar) but Mercurial really should be the "de facto" choice
> for most of the Devs. Once the server is setup, and I can write a
> nice tutorial on using Mercurial, it would be so much easier for the
> dev's (especially mobile users that are using laptops, or are not
> connected to the internet 24/7).
>
> Plus the speed of doing large commits is about 800-1000% faster
> (depending on how many peers are currently online). Since large
> commits are sent to various peers, and then fed back to the main
> server (similar to a torrent/peer/seed type of architecture). This
> way the one main server acts as a "seed" for the developers, and
> it's ALWAYS online, and it "seeds" the network, but transfers are
> done P2P and also fed back to the main seed. That way the "seed"
> always has an up to date version (that is archived and backed up
> nightly).
>
> It may sound like a lot of work, but really it's not. I can get it
> done in about a day or two. Then maybe another day for writing up
> tutorials. Then the dev's can transition to Mercurial at their own
> pace. This way there is no pressure, but the advantages of
> Mercurial (and intelligent merging) really are what would be best
> for a collaborative project like this.
>
> > I don't think we can survive another move.
>
> You just focus on developing, I can do the server build, setup Merc
> and Git and also handle the move. We can save the old Git for
> archival purposes (just leave it where it's at). I can just use the
> new box for Git and Mercurial (for the dev's) and then feed the new
> repository back to the old Git (for an extra online archival as well).
>
> This way the dev's can move over to the new Mercurial (at their own
> will), and the new repository server will handle everything (and the
> old Git will just be used for archival purposes).
>
> > Also, I don't want to learn another toolchain, I want to develop.
>
> With TortoiseHG you don't have to learn anything. You just point,
> and right click. You don't need to know any commands, don't need to
> do any packing/repacking of Git, and don't need to do anything. As
> a user/developer Mercurial is by far the easiest to use for
> developers (with the TortoiseHG client installed on your local
> machine).
>
> I can administer the repository, and do backups/snapshots. That way
> the dev's don't have to worry about anything. If someone/something
> borks something, then just let me know and I can just do a restore
> (if needed). But this way the dev's can just focus on developing.
>
> > *> 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. *
>
> This way you don't have to deal with the headaches of manually
> syncing branches, and you can spend your time developing instead of
> resolving conflicts by hand. ;-)
>
> Intelligent merging has been around for quite a while, and using
> something like Git or Subversion (in today's day in age) really
> seems a bit archaic. With tools like Mercurial and TortoiseHG you
> really don't need to learn (or know) anything as a user/developer.
>
> Just right click on the file, or right click on the folder, and
> commit/merge. It's really quite simple.
>
> http://tortoisehg.bitbucket.org/
>
> It really only takes a few seconds to install TortoiseHG on your
> local machine, and then just right click in file explorer and then
> "create clone" and that's it. <POOF> you're done.
>
> http://draketo.de/light/english/mercurial/short-introduction-mercurial-tortoisehg
>
> It really is that easy. Then when you are ready to commit, just
> right click on a folder and then select "Synchronize" and <POOF>
> you're done. It really is that easy.
>
> Git is a nightmare. I couldn't even imagine using Git for any
> serious collaborative project. You'd spend half of your day just
> handling conflicts manually, and would be pulling your hair out (as
> an administrator) if you were using archaic tools like Git.
>
> Plus just wait a few months, and see how much Git slows down (as the
> project grows) and just wait till you hit a "git-repack" error (or
> run out of memory) and experience your first Git crash. That's when
> you'll be calling your system administrator for help, and wasting a
> day (or two) dealing with the headaches of Git.
>
> http://n2.nabble.com/git-gc-out-of-memory-td4005235.html
>
> Experience a repository corruption, and then you'll be hugging your
> pillow at night wondering what on earth you're going to do next.
>
> If you want headaches, stick with Git. If you want to come out of
> the dark ages, then use Mercurial (or Bazaar).
>
> I support developers, and I at least understand WHY everyone loves
> Mercurial (or Bazaar). It's the fastest/easiest/best to use from
> both a user perspective, and from a system administrator's
> perspective. If you've ever maintained large repositories (on large
> collaborative projects) you'd understand the amount of overhead
> (work that you must spend with Git) and understand the dangers of
> Git (database corruption, memory errors, etc) and then you'll begin
> to understand WHY something like Mercurial or Bazaar is the safest,
> fastest, and best for any large collaborative project. (A good sys
> admin can always run both a Git, and a Mercurial on the same server,
> just in case there are a few users that need some time to transition
> over to Mercurial, but it really only takes about 5 minutes to
> transition over to Mercurial from a user/developer standpoint, and
> the "learning curve" is probably under 2-3 minutes at the most and
> just by skimming over the TortoiseHG client tutorial, it can
> probably answer all your questions in just 2-3 minutes).
>
> It's extremely easy to see the "icon overlays" in File Explorer (as
> you're working). You'll see a nice green checkmark box on the
> folder (if it's currently up to date and synced). If another
> developer has modified a file, or you have modified a file, then you
> will see a blue plus, then just right click on the file or folder
> and "synchronize" and then all the latest changes are now
> synchronized on your machine.
>
> For groups that want to have their own separate branches, or even do
> their own private work, it's extremely simple and easy for users/
> devs to create various group repositories with just a simple right
> click of the mouse. It makes it extremely easy for everyone to
> collaborate (and stay "up to date")
>
> http://tortoisehg.bitbucket.org/manual/0.9/quick.html
>
> Mercurial (or Bazaar) really does make collaboration easy.
> Subversion, CVS, and Git are really from the dark ages. Once you
> experience a repository "hiccup" then you'll understand what I
> mean. ;-)
>
> A user/developer wants to rename a file? Just right-click, "rename"
> the file, then "synchronize" it's really that easy. Intelligent
> merging really does make life simple (Mercurial and Bazaar are
> designed to do these things). Mercurial also supports file and
> directory copies.
>
> I could always setup Git, Mercurial, and Bazaar on a dedicated
> server, and then just let the dev's each decide what they want to
> use. I personally don't care, but once the Dev's move over to
> Mercurial (or Bazaar) they'll understand how easy it really is (and
> how simply it is).
>
> Git is a headache to administer, and as a collaborative project
> grows you'll probably waste half of your time (as a developer) with
> commits & merging headaches (with Git) but you'd be quite thankful
> of Mercurial (especially if you synchronize regularly, like once an
> hour while connected to the internet).
>
> This way you're always up to date, and it's extremely fast using
> Mercurial.
>
> http://hgbook.red-bean.com/
>
> I can setup a nice repository server (with Git, Mercurial, and
> Bazaar) that way the dev's can just use Mercurial (P2P) and the
> server can do the backups, archiving, and also feed back to the old
> Git Server (for online archival purposes).
>
> Mercurial is the fastest, most intelligent and by far the best
> (Bazaar is good as well). P2P architecture works well, and it there
> are plenty of "safeguards" to protect the repository (since each
> local machine . This way there is plenty of "safeguards" and
> redundancy. The last thing you want is to mess around with Git, and
> then have a repository/database corruption (or out of memory/malloc
> failure).
>
> http://gist.github.com/288395
>
> or a malloc failture:
>
> http://lists-archives.org/git/705317-git-gc-out-of-memory.html
>
> Plus with Mercurial you don't need to do all the "house keeping"
> that you need to do with Git and don't need to manually repack or
> prune.
>
> http://blog.felipebalbi.com/2007/12/19/housekeeping-your-git-repository/
>
> Git is a lot of work, and Mercurial is about 8-10 times faster than
> Git (over time) unless you dedicate the time to manually maintaining
> Git. It's quite a bit of time/work and Mercurial (or Bazaar) just
> don't have all these headaches or speed / performance / maintenance
> issues. From a user's standpoint, and a system administrator's
> standpoint, Mercurial (or Bazaar) are by far the two that are the
> fastest, easiest, and simplest to maintain. Git is a headache.
>
> Mark
>
>
>
>
> On Mon, Feb 22, 2010 at 5:15 PM, Melanie <melanie at t-data.com> wrote:
> 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
> _______________________________________________
> 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/2f4dea6e/attachment-0001.html>
More information about the Opensim-dev
mailing list