> 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.
>
Yes, this would work fine. One small change that could simplify things
would be to plan carefully the order in which you apply commits to the
various branches. For example, if a change needs to be applied to both the
2.2 branch and the default branch, you would first apply it to the 2.2
branch and then merge it directly onto the default branch without having to
make any additional edits to the code on the default branch. You don't
generally want to merge from default to the 2.2 branch since you'll pull
all the development commits onto the release branch, and that's not usually
what you intend. Under the separate repo model, you essentially copy and
paste patches between the two repositories (or you can pull between them,
but that has not been the historical model for Spyder), and the order in
which you make the commits doesn't matter as much if you are just sharing
patches back and forth. But you loose a bit of visibility into how the two
branches relate to each other under this model.
In that light, a more likely workflow model would be to have a main clone
of the default repo in which you are making code changes and a second local
clone (a clone of the main clone) from which you execute the application.
To apply a bug fix to the release branch and the default branch, you'd
update to the 2.2 branch in the main clone, launch Spyder from the second
local clone (updated to whatever state you desire), and use that Spyder
instance to edit the files from the main clone to create the fix. Once the
change is done, you commit to the 2.2 branch, update back to the default
branch and merge the change over from the 2.2 branch. For new development
features that are only going into the default branch you'd just update to
the default branch in your main clone and commit directly to the default
branch, leaving the 2.2 branch alone.
> 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.
>
>
This is certainly possible. I did it this afternoon in local copies of the
repositories. But I don't think it would be advisable since all of the v21
commits show up on the default branch and can't really be moved to another
named branch. As a result it isn't as easy to identify the v21 branch.
Remember that the branch name is embedded in the commit itself, and it's
not possible to change the branch name post-commit. At best you could
assign the v21 series of commits to a bookmark. I would leave the v21
repository as-is and just create the first named branch in the default
repository for 2.2 if you decide to go that route instead of
branch-by-clone.
--
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.
