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 > <lo...@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: >> >> > d...@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@lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev@lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev