It has probably become quite apparent over the last few months that pyglet is not being maintained or developed. Both Richard and I have become quite occupied with other, er, occupations this year, and without the necessary free time to devote to pyglet.
Richard and I started working on pyglet in August 2006, initially as an experimental OpenGL front-end for Python, and then as an alternative to PyGame/SDL. Looking at the early design documents [1], it's satisfying to note that all of the main goals were achieved, and most of the "pie in sky" ideas have been implemented as modules specifically for pyglet by other developers.
In June 2007 the pyglet 1.0alpha1 was published, and after months of fairly intensive testing, feedback and fixing from hundreds of developers, pyglet 1.0 was released in early 2008. pyglet-1.1, released in August 2008, has been downloaded some 13,000 times.
While there have been no subsequent releases or feature enhancements since then, the pyglet community continues to grow. There are currently 670 members in the pyglet-users mailing list, with a new member joining every one or two days.
The issue tracker is currently filled not just with bug reports, but also many patches for those bugs which have yet to make it into the code base. Many bugs that have been fixed in trunk have not been back-ported to the maintenance branch. At this stage it appears that mine and Richard's non-involvement with pyglet is harming the project.
If you have some time to contribute to pyglet, I invite you now to do so directly. Email me privately with your Google account ID (email address) so I can add you to the googlecode project committer list. This will give you full access to SVN, the issue tracker and wiki.
I am not restricting access to people with specific patches to commit or ideas to implement. For example, there is substantial work available just in verifying issues in the tracker, applying patches and closing duplicates. The trunk is a mostly-complete refactor of the codebase with several new features that possibly just needs documentation and fixes to complete. I'm hoping that some sort of semi-organised anarchy will form to continue pyglet maintenance and development.
I am looking forward to granting you all commit access!
On Aug 13, 1:59 pm, Alex Holkner <alex.holk...@gmail.com> wrote:
> If you have some time to contribute to pyglet, I invite you now to do
> so directly. Email me privately with your Google account ID (email
> address) so I can add you to the googlecode project committer list.
> This will give you full access to SVN, the issue tracker and wiki.
> I am looking forward to granting you all commit access!
I don't think that'd work particularly well. I would suggest switching
to a dvcs and following the Linux model, where Alex becomes Linus,
Richard and whoever else becomes core developers and everybody else
who wants his favorite patch in becomes a contributor that has to go
trough the gates of the core teams pull/push. Alex and Richard would
still have some work in the short term, but it'd allow to build a core-
team that could eventually replace them and ensure a continuing
quality of changes.
> I don't think that'd work particularly well. I would suggest switching > to a dvcs and following the Linux model, where Alex becomes Linus, > Richard and whoever else becomes core developers and everybody else > who wants his favorite patch in becomes a contributor that has to go > trough the gates of the core teams pull/push. Alex and Richard would > still have some work in the short term, but it'd allow to build a core- > team that could eventually replace them and ensure a continuing > quality of changes.
I disagree, because: 1. I don't like DVCS. 2. Someone has to do the repository migration. (Are you volunteering?) 3. As you said yourself, "playing Linus" still takes some time, which defeats the whole point of the exercise.
I agree with Florian and I think that giving full SVN access to
anybody might make things a real mess in a short period of time. We
need some sort of roadmap and identify priorities (bug fix, adding
feature, doc, ...). I think Alex made a fantastic job with the pyglet
abstraction and I would be happy to code for pyglet under his
direction. Also, there is already a lot of contribution that could
make it into pyglet (gletools, simplui/kytten, ...).
Nicolas
On Aug 14, 7:42 am, Florian Bösch <pya...@gmail.com> wrote:
> On Aug 13, 1:59 pm, Alex Holkner <alex.holk...@gmail.com> wrote:
> > If you have some time to contribute to pyglet, I invite you now to do
> > so directly. Email me privately with your Google account ID (email
> > address) so I can add you to the googlecode project committer list.
> > This will give you full access to SVN, the issue tracker and wiki.
> > I am looking forward to granting you all commit access!
> I don't think that'd work particularly well. I would suggest switching
> to a dvcs and following the Linux model, where Alex becomes Linus,
> Richard and whoever else becomes core developers and everybody else
> who wants his favorite patch in becomes a contributor that has to go
> trough the gates of the core teams pull/push. Alex and Richard would
> still have some work in the short term, but it'd allow to build a core-
> team that could eventually replace them and ensure a continuing
> quality of changes.
I agree that opening the repository to everyone interested could be a
problem; if in a short period of time Alex could spot some talend
contributors that share the same vison of pyglet, the work of
patch/code review can be offloaded to said developers
p.s. I've done a quick research in "vcs to dvcs migration" topic and
it seems that it's not that difficult to migrate subversion to
mercurial; I can try to do the migration if you agree
2009/8/14 Nicolas Rougier <nicolas.roug...@gmail.com>:
> I agree with Florian and I think that giving full SVN access to
> anybody might make things a real mess in a short period of time. We
> need some sort of roadmap and identify priorities (bug fix, adding
> feature, doc, ...). I think Alex made a fantastic job with the pyglet
> abstraction and I would be happy to code for pyglet under his
> direction. Also, there is already a lot of contribution that could
> make it into pyglet (gletools, simplui/kytten, ...).
> Nicolas
> On Aug 14, 7:42 am, Florian Bösch <pya...@gmail.com> wrote:
>> On Aug 13, 1:59 pm, Alex Holkner <alex.holk...@gmail.com> wrote:
>> > If you have some time to contribute to pyglet, I invite you now to do
>> > so directly. Email me privately with your Google account ID (email
>> > address) so I can add you to the googlecode project committer list.
>> > This will give you full access to SVN, the issue tracker and wiki.
>> > I am looking forward to granting you all commit access!
>> I don't think that'd work particularly well. I would suggest switching
>> to a dvcs and following the Linux model, where Alex becomes Linus,
>> Richard and whoever else becomes core developers and everybody else
>> who wants his favorite patch in becomes a contributor that has to go
>> trough the gates of the core teams pull/push. Alex and Richard would
>> still have some work in the short term, but it'd allow to build a core-
>> team that could eventually replace them and ensure a continuing
>> quality of changes.
>> Cheers,
>> Florian
-- "Rendete ogni cosa il più semplice possibile, ma non di più" (Albert Einstein)
"You are what you choose today, not what you've chosen before"
"Unix IS user friendly. It's just selective about who its friend are"
2009/8/14 Francesco Pischedda <francesco.pische...@gmail.com>:
> I agree that opening the repository to everyone interested could be a > problem; if in a short period of time Alex could spot some talend > contributors that share the same vison of pyglet, the work of > patch/code review can be offloaded to said developers
> p.s. I've done a quick research in "vcs to dvcs migration" topic and > it seems that it's not that difficult to migrate subversion to > mercurial; I can try to do the migration if you agree
Sounds great. I've only used Git but I too like DVCS. I suppose Mercurial still makes better sense than Git for Windows development.
On Aug 14, 8:43 am, Seo Sanghyeon <sanx...@gmail.com> wrote:
> I disagree, because:
> 1. I don't like DVCS.
I presume you have a better solution to distribute the workload of
decentralized development then.
> 2. Someone has to do the repository migration. (Are you volunteering?)
It looks like francesco.pischedda is volunteering, I could as well.
> 3. As you said yourself, "playing Linus" still takes some time, which
> defeats the whole point of the exercise.
Not quite. Building a core-team of gatekeepers will take some time,
and regardless of what vcs you use, trying to get there with the help
of the lead developer will be far smoother then letting anarchy ensue,
in my opinion.
> I agree with Florian and I think that giving full SVN access to > anybody might make things a real mess in a short period of time. We > need some sort of roadmap and identify priorities (bug fix, adding > feature, doc, ...). I think Alex made a fantastic job with the pyglet > abstraction and I would be happy to code for pyglet under his > direction. Also, there is already a lot of contribution that could > make it into pyglet (gletools, simplui/kytten, ...).
Alex and I believe that pyglet should not grow in scope (actually, Alex would argue that pyglet covers too much scope right now). It should be a solid core on which those 3rd party libraries may be developed. See the design document link that Alex posted in his email[1].
To that end the open SVN access isn't really that great a problem: there should always be a tight rein on any sort of feature creep and definitely an eye for backwards compatibility in any commit.
Let's see how we go with contributors using SVN before we jump off on any DVCS tangent.
> Alex and I believe that pyglet should not grow in scope (actually, > Alex would argue that pyglet covers too much scope right now). It > should be a solid core on which those 3rd party libraries may be > developed. See the design document link that Alex posted in his > email[1].
> To that end the open SVN access isn't really that great a problem: > there should always be a tight rein on any sort of feature creep and > definitely an eye for backwards compatibility in any commit.
Something that would be really useful for those of us interested in continuing the project would be a consensus on what the appropriate scope for Pyglet should be. While that design document is very interesting, and certainly gives a feeling for the flavour of Pyglet, it's somewhat out of date, as far as current Pyglet development goes.
I'd be very interested to hear both Richard and Alex's opinions on this matter, as they're the most familiar with Pyglet from a technical perspective. In particular, the future of the "experimental" branch is something I'd like to talk about.
While I'm with Alex on the idea of "semi-organised anarchy", we have just increased the number of people who can make commits by more than a factor of five. I think we need to start thinking about what form that semi-organisation should take.
I've used a combination of svnsync and hg convert to create a hg
repository from the google svn one. I'm hosting it on my server and
its also pushed to bitbucket.
I'm going to add some patches which I need (mainly concerned with
evdev). You can let me know if you have some repo you want me to pull
from or send me quilts/patchsets via email.
I mentioned switching to a DVCS to Alex in another email, and he said
it wouldn't be hard for us to use hg-svn for our working copies and
treat the svn server as a push target. Is that an acceptable solution,
or are there other factors?
I wold also be in favor of switching over to a DVCS completely,
preferably hg because Google Code supports it.
On Aug 14, 7:35 am, Florian Bösch <pya...@gmail.com> wrote:
> I've used a combination of svnsync and hg convert to create a hg
> repository from the google svn one. I'm hosting it on my server and
> its also pushed to bitbucket.
> I'm going to add some patches which I need (mainly concerned with
> evdev). You can let me know if you have some repo you want me to pull
> from or send me quilts/patchsets via email.
> I mentioned switching to a DVCS to Alex in another email, and he said > it wouldn't be hard for us to use hg-svn for our working copies and > treat the svn server as a push target. Is that an acceptable solution, > or are there other factors?
> I wold also be in favor of switching over to a DVCS completely, > preferably hg because Google Code supports it.
I think a lot of this is tied up in the question of where the future of Pyglet lies. If we're going to be adding heaps of new functionality, which Richard and Alex are both against, and which I at least have fairly strong reservations about, then yes, we probably need a DVCS system. However, if we're considering Pyglet to be roughly feature-complete, and only talking about bug fixes and minor enhancements, then the current SVN system seems perfectly acceptable.
At the moment, it seems like people have a new toy, and are rushing to play with it. Let's sit back, fix the bugs that we've got, and have a discussion about where we'd like things to go, development-wise. Then we can decide what the appropriate technical solution should be.
On Aug 14, 1:47 pm, "Martin O'Leary" <m.e.w.ole...@gmail.com> wrote:
> I think a lot of this is tied up in the question of where the future
> of Pyglet lies. If we're going to be adding heaps of new
> functionality, which Richard and Alex are both against, and which I at
> least have fairly strong reservations about, then yes, we probably
> need a DVCS system. However, if we're considering Pyglet to be roughly
> feature-complete, and only talking about bug fixes and minor
> enhancements, then the current SVN system seems perfectly acceptable.
I don't think SVN is suited if many people want to contribute.
1) if you give everybody commit rights, chaos ensues.
2) if you limit commit access to a small number of people, the whole
burden of reviewing/applying patches falls onto their shoulders.
A DVCS is actually better suited to distribute the workload of moving
a project forward, whatever the destination, be that less bugs or more
features.
I also would prefer to have first bug fixed and then take time to
think on whether some features are necessary and how to integrate them
within the existing architecture. If there is no principal maintainer
anymore, I guess we also need some procedure to decide whether or not
to include this or that feature. In this context, having a minimal
bulletproof pyglet would certainly help further development.
>> I mentioned switching to a DVCS to Alex in another email, and he said
>> it wouldn't be hard for us to use hg-svn for our working copies and
>> treat the svn server as a push target. Is that an acceptable
>> solution,
>> or are there other factors?
>> I wold also be in favor of switching over to a DVCS completely,
>> preferably hg because Google Code supports it.
> I think a lot of this is tied up in the question of where the future
> of Pyglet lies. If we're going to be adding heaps of new
> functionality, which Richard and Alex are both against, and which I at
> least have fairly strong reservations about, then yes, we probably
> need a DVCS system. However, if we're considering Pyglet to be roughly
> feature-complete, and only talking about bug fixes and minor
> enhancements, then the current SVN system seems perfectly acceptable.
> At the moment, it seems like people have a new toy, and are rushing to
> play with it. Let's sit back, fix the bugs that we've got, and have a
> discussion about where we'd like things to go, development-wise. Then
> we can decide what the appropriate technical solution should be.
> > I mentioned switching to a DVCS to Alex in another email, and he said
> > it wouldn't be hard for us to use hg-svn for our working copies and
> > treat the svn server as a push target. Is that an acceptable solution,
> > or are there other factors?
> > I wold also be in favor of switching over to a DVCS completely,
> > preferably hg because Google Code supports it.
> I think a lot of this is tied up in the question of where the future
> of Pyglet lies. If we're going to be adding heaps of new
> functionality, which Richard and Alex are both against, and which I at
> least have fairly strong reservations about, then yes, we probably
> need a DVCS system. However, if we're considering Pyglet to be roughly
> feature-complete, and only talking about bug fixes and minor
> enhancements, then the current SVN system seems perfectly acceptable.
> At the moment, it seems like people have a new toy, and are rushing to
> play with it. Let's sit back, fix the bugs that we've got, and have a
> discussion about where we'd like things to go, development-wise. Then
> we can decide what the appropriate technical solution should be.
> I don't think SVN is suited if many people want to contribute. > 1) if you give everybody commit rights, chaos ensues. > 2) if you limit commit access to a small number of people, the whole > burden of reviewing/applying patches falls onto their shoulders.
> A DVCS is actually better suited to distribute the workload of moving > a project forward, whatever the destination, be that less bugs or more > features.
At the moment we have 11 "contributors", including Richard and Alex. I think we can safely assume that not all of these people are going to be regular contributors - everyone starts with the best of intentions, but interest is going to wane after time. I think we can assume a maximum of ten people contributing in the long term, with only about half that number genuinely working on the project on a regular basis. Even those numbers seem quite optimistic to me, and they don't sound like they're going to lead to chaos.
Pyglet isn't GNOME or the Linux kernel. It's a fairly small project, with a small number of users. Switching to a DVCS is a technical solution to a social problem that doesn't exist, and I think it's distracting from the discussion we ought to be having, which is that of the future of the project in general.
On Aug 14, 3:01 pm, "Martin O'Leary" <m.e.w.ole...@gmail.com> wrote:
> 2009/8/14 Florian Bösch <pya...@gmail.com>:
> At the moment we have 11 "contributors", including Richard and Alex. I
> think we can safely assume that not all of these people are going to
> be regular contributors - everyone starts with the best of intentions,
> but interest is going to wane after time. I think we can assume a
> maximum of ten people contributing in the long term, with only about
> half that number genuinely working on the project on a regular basis.
> Even those numbers seem quite optimistic to me, and they don't sound
> like they're going to lead to chaos.
> Pyglet isn't GNOME or the Linux kernel. It's a fairly small project,
> with a small number of users. Switching to a DVCS is a technical
> solution to a social problem that doesn't exist, and I think it's
> distracting from the discussion we ought to be having, which is that
> of the future of the project in general.
If you want, you can ignore the distributed nature of mercurial and
continue working with it as if it was SVN. I've left SVN behind some
years ago, and I appreciate the flexibility of it when its handy. The
social problem might or might not exist, or it might or might not
arise, but sticking to a centralized vcs you'll never know, because
you'll have forced people into one way to interact. I'm not going to
go trough the hassle with SVN again and I'll stick to DVCSes for easy
cloning, pulling, pushing, merging, queue adding/dropping and patchset
application.
On Fri, Aug 14, 2009 at 8:55 AM, Tartley <tart...@tartley.com> wrote:
> +1. I like pyglet because it doesn't try to be a PyGame - while that > is a worthy endeavour, it's not what I'm looking for here.
+1 for trimming pyglet down, rather than adding features.
I would personally like to see pyglet.graphics, pyglet.font and pyglet.text broken out into their own library - they are just bloat if you are doing anything fancy with pyglet.
> On Aug 14, 12:47 pm, "Martin O'Leary" <m.e.w.ole...@gmail.com> wrote: > > 2009/8/14 Steve Johnson <dior...@gmail.com>: > I think a lot of this is > tied up in the question of where the future > > of Pyglet lies. If we're going to be adding heaps of new > > functionality, which Richard and Alex are both against, and which I at > > least have fairly strong reservations about, then yes, we probably > > need a DVCS system. However, if we're considering Pyglet to be roughly > > feature-complete, and only talking about bug fixes and minor > > enhancements, then the current SVN system seems perfectly acceptable.
> > At the moment, it seems like people have a new toy, and are rushing to > > play with it. Let's sit back, fix the bugs that we've got, and have a > > discussion about where we'd like things to go, development-wise. Then > > we can decide what the appropriate technical solution should be.
I've been reading this thread with interest. I would like to help out
on pyglet maintenance, particularly I'd be interested (for now) in
doing the appropriate things to open issues. So far, I've been
pleased with the scope of pyglet, though I haven't used the font and
text stuff myself(yet).
I think what should be done for the immediate future of pyglet is to
take care of all of the important open issues and get a release out
without a scope change. While that's going on, we can easily discuss
longer-term choices and attempt to determine the fashion in which
pyglet should continue, whether it be a minimalist core with easy ways
to extend, or whether it should become emacs(not a slam on emacs, I <3
it though that's not where I want pyglet to go, myself).
I enjoy DVCS, but sort of as a corollary to the immediate future, we
don't need to jump head first into a different version control system
in order to get an updated release out. I personally can use git
locally and just build patches for what is to be published via svn, no
big deal. Or I can just use svn for now. One issue that comes up in
either case is that some entity(individual or committee) needs to
authoritatively determine whether things are ready for release. What
may be a determining factor for version control is whichever system is
going to match this entity's style and composition best. If that is
the case, before making version control decisions, we need to see how
the next wave of pyglet authority shakes out and we'll have a much
better idea which technologies to apply.
My $0.02,
-b
On Aug 14, 8:08 am, George Oliver <georgeolive...@gmail.com> wrote:
> On Aug 14, 6:24 am, Tristam MacDonald <swiftco...@gmail.com> wrote:
> > On Fri, Aug 14, 2009 at 8:55 AM, Tartley <tart...@tartley.com> wrote:
> > > +1. I like pyglet because it doesn't try to be a PyGame - while that
> > > is a worthy endeavour, it's not what I'm looking for here.
> > +1 for trimming pyglet down, rather than adding features.
> As a pyglet user and not a maintainer/developer, I'd like to add my
> support to the above. I appreciate pyglet for precisely the reasons
> Tartley noted.
Been following all this and for my money switching any part of project
management (whether that be source control, issue tracking, discussion
groups) is not worth the effort for one simple reason: its not about
what's better and what's worse, it's about what works and what
doesn't. It seems that the discussion of DVCS going is trying to solve
a problem that may not exist yet. Switching to a broader base of
developers will cause some problems but would it not be best to see
what those problems are before trying to fix them?
In response to Martin's concerns about the direction that pyglet is
going, obviously I don't know and I don't want to make decisions
without the input of either Alex or Richard but as we have this new
base of interested developers we should get some discussion going
(although possibly pyglet-users is the wrong place for it).
Having just thought about that last comment I speculatively created
the pyglet-devs group.
Richard.
On Aug 14, 6:11 pm, Ben Smith <benjamin.coder.sm...@gmail.com> wrote:
> I've been reading this thread with interest. I would like to help out
> on pyglet maintenance, particularly I'd be interested (for now) in
> doing the appropriate things to open issues. So far, I've been
> pleased with the scope of pyglet, though I haven't used the font and
> text stuff myself(yet).
> I think what should be done for the immediate future of pyglet is to
> take care of all of the important open issues and get a release out
> without a scope change. While that's going on, we can easily discuss
> longer-term choices and attempt to determine the fashion in which
> pyglet should continue, whether it be a minimalist core with easy ways
> to extend, or whether it should become emacs(not a slam on emacs, I <3
> it though that's not where I want pyglet to go, myself).
> I enjoy DVCS, but sort of as a corollary to the immediate future, we
> don't need to jump head first into a different version control system
> in order to get an updated release out. I personally can use git
> locally and just build patches for what is to be published via svn, no
> big deal. Or I can just use svn for now. One issue that comes up in
> either case is that some entity(individual or committee) needs to
> authoritatively determine whether things are ready for release. What
> may be a determining factor for version control is whichever system is
> going to match this entity's style and composition best. If that is
> the case, before making version control decisions, we need to see how
> the next wave of pyglet authority shakes out and we'll have a much
> better idea which technologies to apply.
> My $0.02,
> -b
> On Aug 14, 8:08 am, George Oliver <georgeolive...@gmail.com> wrote:
> > On Aug 14, 6:24 am, Tristam MacDonald <swiftco...@gmail.com> wrote:
> > > On Fri, Aug 14, 2009 at 8:55 AM, Tartley <tart...@tartley.com> wrote:
> > > > +1. I like pyglet because it doesn't try to be a PyGame - while that
> > > > is a worthy endeavour, it's not what I'm looking for here.
> > > +1 for trimming pyglet down, rather than adding features.
> > As a pyglet user and not a maintainer/developer, I'd like to add my
> > support to the above. I appreciate pyglet for precisely the reasons
> > Tartley noted.
I agree with Florian, Opening up the floodgates to the core of pyglet, would hack the system to pieces, leaving nothing to base future development on. Given that the serious "pygleter" would do everything to keep the core intact, there are many of us who with all good intentions, will just mess up the base, due to some small oversight of misconceptions on the "way we would prefer things to be done". A new core team is a controlled migration, that is required move the pyglet gem forwards:) We love your work Alex, don't just go flush it away now.
On 8/14/09, Florian Bösch <pya...@gmail.com> wrote:
> I don't think that'd work particularly well. I would suggest switching > to a dvcs and following the Linux model, where Alex becomes Linus, > Richard and whoever else becomes core developers and everybody else > who wants his favorite patch in becomes a contributor that has to go > trough the gates of the core teams pull/push. Alex and Richard would > still have some work in the short term, but it'd allow to build a core- > team that could eventually replace them and ensure a continuing > quality of changes.
On Fri, Aug 14, 2009 at 7:39 AM, joe hall <jestermons...@gmail.com> wrote:
> I agree with Florian, Opening up the floodgates to the core of pyglet, > would hack the system to pieces, leaving nothing to base future > development on. Given that the serious "pygleter" would do everything > to keep the core intact, there are many of us who with all good > intentions, will just mess up the base, due to some small oversight of > misconceptions on the "way we would prefer things to be done". A new > core team is a controlled migration, that is required move the pyglet > gem forwards:) > We love your work Alex, don't just go flush it away now.
A reasonable compromise is branched development. If we can make the short term goal to reconcile the trunk with the 1.1-maintenance branch, then anyone who wants to experiment with destructive upgrades can be pushed into their own branch.
Either way, someone needs to be designated to guard the trunk - integrate bug fixes, decide when new branches are stable enough to be back-ported to trunk, and decide when to publish new releases.
Alex inquired whether I would be interested in the position, but I don't have enough time to dedicate to managing an entire project at the moment.
> On Fri, Aug 14, 2009 at 7:39 AM, joe hall <jestermons...@gmail.com> wrote:
>> I agree with Florian, Opening up the floodgates to the core of pyglet,
>> would hack the system to pieces, leaving nothing to base future
>> development on. Given that the serious "pygleter" would do everything
>> to keep the core intact, there are many of us who with all good
>> intentions, will just mess up the base, due to some small oversight of
>> misconceptions on the "way we would prefer things to be done". A new
>> core team is a controlled migration, that is required move the pyglet
>> gem forwards:)
>> We love your work Alex, don't just go flush it away now.
> A reasonable compromise is branched development. If we can make the short
> term goal to reconcile the trunk with the 1.1-maintenance branch, then
> anyone who wants to experiment with destructive upgrades can be pushed into
> their own branch.
> Either way, someone needs to be designated to guard the trunk - integrate
> bug fixes, decide when new branches are stable enough to be back-ported to
> trunk, and decide when to publish new releases.
> Alex inquired whether I would be interested in the position, but I don't
> have enough time to dedicate to managing an entire project at the moment.
> --
> Tristam MacDonald
> http://swiftcoder.wordpress.com/
-- "Rendete ogni cosa il più semplice possibile, ma non di più" (Albert Einstein)
"You are what you choose today, not what you've chosen before"
"Unix IS user friendly. It's just selective about who its friend are"
<francesco.pische...@gmail.com> wrote:
> well, private branch are the common and required features of dvcs-es and I agree
Using mercurial you can either:
1) create a branch (named or unnamed) and continue developing it,
merging changes in from the tip as you go, when you commit this head
will be visible.
2) create a clone of the repository where you work on the changes,
pull and merge from the upstream repository and when you're done
commit, no new branch will be created for others.
3) create a Queue which gets re-applied after you've pulled from
upstream repositories, therefore creating a local "view" of what you
do, you can add/drop the whole queue at any time (particularly handy
if somebody wants to try out your changes with his own non published
clone)
I really don't see what's the handwaving over "ohno don't change the
VCS". It's a nobrainer. mercurial is as easy to use as SVN (it allows
you to ignore most of the fancy features), it is a hell of a lot
faster doing a full checkout, it's a hell of a lot faster displaying
diffs, it's a *lot* more flexible, the migration to it has been done
and closed...
Now you can cry all you want how this is a solution in search of a
problem, or how it's all to risky or you simply hate DVCSes, at the
end of the day, Mercurial *is* better then SVN in every respect.
