On 11/29/07, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> CVS makes this process hard and error prone. Subversion probably isn't
> as bad as CVS in this regard, but ever since I started using Mercurial,
> I've had no desire to dig deeper into Subversion. Mercurial gets more
> done with fewer comma
On Thu, 29 Nov 2007 at 22:48 -0700, Shane Hathaway wrote:
> Note that I chose to make the change in ~/stable first, allowing me to
> use Mercurial's standard merge mechanisms. If I had chosen to make the
> change in ~/devel first, I would have to cherry-pick, which is not
> nearly as simple.
Than
Dave Smith wrote:
> My scenario is very similar to the one you describe, but backwards. I
> usually do a release, branch the code (in Subversion or CVS), and
> continue on with new development in the trunk, making only bug fixes
> (theoretically) in the branch. After branching, if a customer reques
On Thu, 29 Nov 2007 at 09:36 -0700, Dave Smith wrote:
> I haven't used it, but it seems that for me the main problem with quilt
> is when files change names (or move to entirely new directories) between
> the development and stable branches. This is why VCS integration is
> critical, because it
I haven't used it, but it seems that for me the main problem with quilt
is when files change names (or move to entirely new directories) between
the development and stable branches. This is why VCS integration is
critical, because it knows where the files went and how to "patch" the
patches in
Dave,
Indeed what you mention is a common use case and a very important one.
Ideally, the VCS would allow you to cherry pick that patch to stable and
merge it into unstable (of course you may have to manually intervene in
the merge process... but you may not).
Darcs does allow this, and it works
Hans Fugal wrote:
Here's the scenario. Consider two branches of a source tree, let's call
them stable and unstable for the purposes of this discussion, but they
could be e.g. Andrew Morton's tree and Linus' tree, or whatever. A bug
is noticed by the unstable dev, and fixed. Now, or later, we want
On Fri, 16 Nov 2007 at 16:08 -0700, Shane Hathaway wrote:
> This sounds similar to the thinking behind Mercurial's Queues extension.
> Have you evaluated that?
>
> http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension
>
> Shane
Yes, I like it very much. It does indeed help the problem, if
Hans Fugal wrote:
> I have on occasion used darcs' cherry picking support, but mostly for
> simple changes that had no dependencies in the first place (e.g. config
> file changes). My hypothesis is that there is no real practical use case
> where the ability to cherry pick is really important. The
On Thu, 15 Nov 2007 at 12:00 -0700, Jonathan Ellis wrote:
> On 11/15/07, Hans Fugal <[EMAIL PROTECTED]> wrote:
> > In my case, I'm trying to decide whether to abandon darcs for
> > mercurial (hg) or hold out hope that one day darcs will get over the
> > exponential merge problem. Right now I sit on
On 11/15/07, Hans Fugal <[EMAIL PROTECTED]> wrote:
> In my case, I'm trying to decide whether to abandon darcs for
> mercurial (hg) or hold out hope that one day darcs will get over the
> exponential merge problem. Right now I sit on the fence. I use hg
> sometimes and darcs other times. I'm quite
I've been thinking about distributed revision control systems again, and
I want to start a discussion about cherry picking.
Here's the scenario. Consider two branches of a source tree, let's call
them stable and unstable for the purposes of this discussion, but they
could be e.g. Andrew Morton's
12 matches
Mail list logo
