Thanks Ben I think I get it now.
Cheers for your time,
Adam.

On 30 January 2010 01:53, Ben Smith <[email protected]> wrote:

> It does what it can automatically, but there are situations where you
> still must resolve conflicts by hand.
>
> -b
>
> On Jan 29, 5:16 pm, Adam Bark <[email protected]> wrote:
> > 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]<pyglet-users%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/pyglet-users?hl=en.
>
>

-- 
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.

Reply via email to