On 29 January 2010 19:22, Ben Smith <[email protected]> wrote:
> To answer your last question first, yes, commit authorization should > be the same. > > Mercurial (aka hg) and git are what I have some experience with, along > with SVN and CVS - so this is from that context. > > Both hg and git are geared around branchy development with multiple > people doing commits. As soon as you clone a repository, you've got > the whole thing there on your disk. You can hop back and forth in the > project's history without talking with the server. You can clone it > from your disk again, without talking to the server. Since these are > local operations, they are very fast. With subversion, going through > history and changing branches requires server communication. > > Since you've got the repository local, you can make changes and commit > them locally, then when you're satisfied with them, push them up to > the server all at once. This is also handy if you want to hack on > something but you're going to be offline - suppose you want to do a > few different things to the source code, fix a bug, add a feature. In > the SVN world, you'd end up with several files modified for different > reasons and have to cherry pick commits to make a coherent history. > With a local repository, you can commit each change in its context, > then push them to another repository with a coherent history for free. > > One additional useful feature is that you can publish your repository, > either temporarily hosted from your machine in a trusted environment, > or set up something more secure for long term public hosting. This > way a maintainer could go through your repo and cherry pick the > patches they'd like to put in the main source archive, and they can do > this with full project history on both your end and their end. As > soon as they clone your repository, they have all the changes they > need locally and don't need to hit your repository again until they > want an update. > > These tools allow for more flexible development workflows while at the > same time making it simpler and faster to branch and merge changes > from many sources. > > And I'm not against SVN, it is an effective tool. > > -b > > On Jan 29, 10:13 am, Adam Bark <[email protected]> wrote: > > On 24 January 2010 18:35, Ben Smith <[email protected]> > wrote: > > > > > Also, to open up a fun can of worms - now seems like a good time to > > > move to a dvcs, particularly Mercurial since google code supports it. > > > Are there compelling reasons to stick with SVN? I'd used git before > > > this discussion came up in August, and have been working with both git > > > and Mercurial since. A lot of the issue ports and backports would > > > have been easier with one of these, due to the overhead in tracking > > > down historical diffs to find out which things changed and when. I > > > would personally prefer working with hg over SVN. > > > > I still don't really "get it" as far as dvcs's go can you explain it at > all? > > Does everybody that had rights on the SVN server get it on Mercurial? > > > > Cheers, > > Adam. > Thanks a lot for that explanation it was very helpful, quick question though; if two people are working on the same thing how does it go about merging the two different sets of commits into something coherent? Cheers, Adam. -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
