> 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 <[email protected]> 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
> <[email protected]>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:
>>
>> > [email protected] 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
>> >> [email protected]
>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >>
>> >
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > [email protected]
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [email protected]
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
