Jed: yes, this is what I'm suggesting. It seems like when you create a new repo every time you switch you are losing information about the lineage and relationships between revisions.
My situation is some colleagues added modifications to 2.0.10 and I want to rebase up to current. Since this development was done in the v20 repo there doesn't seem to be a clear path to getting back to the master repo. Maybe I am incorrect in this assumption? Your comment makes it seem like you know a way to merge between the repos. How is this done? On Jan 20, 4:25 pm, Jed Ludlow <[email protected]> wrote: > > We have to do create a new repository (or branch) every time we switch > > a version to maintenance mode. Otherwise we couldn't do real > > corrective maintenance. It allows to start working on the next version > > and do major changes without hesitation and without the necessity of > > merging the new development branch with the stable branch because that > > would represent too much work. And that is the only way I know to keep > > maintaining a version while working on a new one and releasing on both > > branches. > > > -Pierre > > Pierre, it is possible to manage multiple stable release branches within > the same repository [1], and a workflow like this is perhaps what Steve is > suggesting. That said, it is equally valid to manage them by cloning as you > are doing today. Changes can be pulled between repositories with nearly the > same effort as merging between branches within the same repository. > > 1.http://ellislab.com/blog/comments/branchy_management_in_mercurial -- You received this message because you are subscribed to the Google Groups "spyder" 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/spyderlib?hl=en.
