Missing tags in Mercurial
41 views
Skip to first unread message
Steve
Jan 18, 2012, 5:00:07 PM1/18/12
to spyder
There are no tags for 2.0.9 or 2.0.10 in Mercurial. Can you please
create these?
P.S. Is this the correct venue for this kind of request?
create these?
P.S. Is this the correct venue for this kind of request?
anatoly techtonik
Jan 19, 2012, 5:31:59 PM1/19/12
to spyd...@googlegroups.com
This is correct venue, but tracing the exact Mercurial revision is a challenge. If you can tell the revision (I guess the start is version 2.0.8 at http://code.google.com/p/spyderlib/source/list?name=v2.1.0&r=e72885217dcdafde733bc0586a2713dfdd66fc0b) then there is no problem in creating it. I suspect that 'hg bisect' and 'diff' can somehow help here.
But it also may happen that these releases were made to fix some bugs in a separate branch, which was never merged back to trunk/
Steve
Jan 20, 2012, 10:19:53 AM1/20/12
to spyder
Yeah, I found the tag in V20... Is that a subrepo or what?
On Jan 19, 4:31 pm, anatoly techtonik <techto...@gmail.com> wrote:
> This is correct venue, but tracing the exact Mercurial revision is a
> challenge. If you can tell the revision (I guess the start is version 2.0.8
> athttp://code.google.com/p/spyderlib/source/list?name=v2.1.0&r=e7288521...)
On Jan 19, 4:31 pm, anatoly techtonik <techto...@gmail.com> wrote:
> This is correct venue, but tracing the exact Mercurial revision is a
> challenge. If you can tell the revision (I guess the start is version 2.0.8
Steve
Jan 20, 2012, 2:07:46 PM1/20/12
to spyder
Why are multiple repos being used? This seems detrimental to long
term maintenance and version tracking. Can we avoid this practice in
the future?
term maintenance and version tracking. Can we avoid this practice in
the future?
Pierre Raybaut
Jan 20, 2012, 5:15:21 PM1/20/12
to spyd...@googlegroups.com
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.
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
> --
> You received this message because you are subscribed to the Google Groups "spyder" group.
> To post to this group, send email to spyd...@googlegroups.com.
> To unsubscribe from this group, send email to spyderlib+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/spyderlib?hl=en.
>
Jed Ludlow
Jan 20, 2012, 5:25:27 PM1/20/12
to spyd...@googlegroups.com
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
Steve
Jan 20, 2012, 5:40:13 PM1/20/12
to spyder
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?
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?
Jed Ludlow
Jan 21, 2012, 8:45:20 AM1/21/12
to spyd...@googlegroups.com
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?
The ability to pull change sets from any repository into any other repository is a fundamental feature of Mercurial, and it's what makes Pierre's current approach of stable-branch-by-clone as valid as stable-branch-in-repo. See the section "Sharing changes" on this page:
http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html
If you're using TortoiseHg, see this:
http://tortoisehg.bitbucket.org/manual/2.0/sync.html
Reply all
Reply to author
Forward
0 new messages