[Opensim-dev] Status of presence refactor?

Tue Feb 23 01:23:18 UTC 2010

Hi,

<rant>

skipped _everything_ from the first mention of "Tortoise"....

Apparently, you don't know much about the people you are so eager to
support.

I use Linux, and work exclusively on the command line. I don't use
any Windows OS at all. Also, I'd sooner be found dead that be found
using a development GUI/IDE.

Everyone here knows that. I'm vocal enough about it.

</rant>

Outside of that, your generosity is appreciated, but I, for one, am
not interested in Mercurial at this time.

Also, I don't believe that we would be happy to see an external
contributor manage our repo. It is on our own servers and currently
managed by myself, an OpenSim core member.

I could probably install Mercurial myself, but I am, as already
stated, not interested in learning yet another DVCS's semantics and
toolchain.

The dust on the git migration has barely settled and we're happy for
now, even I, as the "merge mistress".

I believe further treatises on Mercurial are not required at this time.

Melanie

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