Le 29 déc. 2012 à 05:56, "Carlos Córdoba" <[email protected]> a écrit :
I'll be fine with maintaining just one repo. It'd make our lives easier
but our current model is not that bad either.
Like Carlos, I am tempted by the "named branches" approach but I'm also
fine with our current model. Moreover, as I understand it, you can't work
on multiple branches at the same time (which seems normal) and when I work
on Spyder with Spyder, I always have two versions of Spyder running at the
same time. With named branches, I could do it (by creating two directories
and "hg updating" them to revisions associated with two different branches)
but I would have to regularly pulled changes from a repository to another
to keep them synchronized. Hmmm... While I'm writing this, I realize that
it's not really necessary: I suppose I can push two different
repo/directories (which are clones of each other, originally) to the remote
GoogleCode repository without having to synchronize them first, providing
the fact that I'm committing on two different named branches. So it would
not change my old habits to move to a "named branches" model.
If we do, it could be interesting to check if there is a way to reunite two
repositories with a common history ("default" and "v21" GoogleCode
repositories) so that the "v21" repository would become the "v21" named
branch of the "default" repository.
Guys, I'll be mostly offline for three or four days. I was reviewing Jed's
branches but i couldn't finish them. I'll try to merge them but can't
promise anything, sorry.
No problem Carlos.
I'll be offline the whole week-end too (just checking my emails with my
phone like right now).
Cheers,
Pierre
Cheers,
Carlos
El 28/12/12 12:42, Jed Ludlow escribió:
From a logistical perspective, are you thinking of a 2.2 release prior
> to the Python 3 migration? If so, it may make sense to either clone the
> default repository to a v22 or create a named v22 branch inside of the
> default repo before the Python 3 migration work. I guess I'm wondering how
> much destabilization you expect from the Python 3 migration.
>
>
As an aside, I recognize that the previous Spyder release branch model has
been to branch-by-clone. I happened to be browsing the main Python
repository (a beautiful model for branchy development in a singe
repository) the other day in TortoiseHg, and I couldn't help but notice how
nicely it presented a clear picture of which branches were affected by each
bug fix. See the attached screenshot. Fixes are applied at the lowest
affected release and then merged on up the chain. It also shows how the 2.7
branch is being managed essentially on it's own since no merges ever
originate from that branch. Furthermore, Tortoise provides the ability to
show only one of the named branches, so if you want to see only the default
branch you just show it alone. Tempting....
--
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.
--
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.
--
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.
