Figuring out a workflow (bzr-svn, local changes I never want to push upstream)

Jelmer Vernooij jelmer at vernstok.nl
Tue Aug 26 06:06:30 BST 2008


On Sat, Aug 16, 2008 at 10:33:09AM -0500, John Arbash Meinel wrote:
> Russel Winder wrote:
[...]

> I'm a bit curious about how the feature branch works, and if you are always
> cherry-picking the last commit, or multiple commits, or what. If you are just
> cherry-picking, why not just use merge rather than rebase. So the workflow
> becomes:

> cd trunk
> bzr pull
> cd ../local
> bzr merge ../trunk
> bzr commit -m "bring in latest trunk"
> cd ../feature
> bzr merge  # you could merge trunk or local, as you have enough ancestry
> bzr commit -m "bring in latest trunk"
> # hack hack
> bzr commit -m "new feature"
> cd ../trunk
> bzr pull # you have to make sure you are in sync
> bzr merge -r -2..-1 ../feature
> bzr commit
> bzr dpush
> bzr pull # I don't know if dpush does pull for you
Yes, it will do the pull as well.

> locally you just use cherry picking back and forth between the 'trunk' branch
> and the feature branch. I don't really see why you need to go through the
> 'local' branch at that point.


> > I claim (but this is from memory of experiments not from recent data)
> > that Git doesn't have this problem.  I believe I can have a git-svn
> > clone of a Subversion repository and then clone that and "svn rebase/svn
> > push" from the Subversion clone and pull/push from the secondary clone
> > -- very much in the way you are working above -- and it all works.
> > Jelmer tells me that the Git rebasing renames the changesets just as
> > Bazaar dpush does.  It seems though that Git's use of repository as the
> > cloned thing rather than a branch as the branched thing means that you
> > don't get the duplication that you do with Bazaar when you merge.

> So, there are a few possibilities.

> 1) git considers the 'tree' hash as well as the 'commit' hash when figuring
> out ancestry. I don't strictly think it does this, but there are at least some
> possibilities here.

> 2) 'git dpush' rebases all branches in your local repository that are based on
> the revisions you are rebasing. So if you have 'local' and 'feature' that are
> based on top of 'trunk', and you 'dpush' trunk (causing it to create new
> revisions for the 'trunk' branch, it also goes around and rebases all the
> other branches that were based on that tip.)
I'm sure git doesn't rebase anything other than the current
branch. It leaves the other branches in your repository alone. Russel
insists that git's dpush equivalent doesn't change the local commits
identity, but in that case

> One way to tell the difference, is to actually create a separate *clone* so
> you have a separate repository. And see if the workflow stays smooth when
> 'feature' is not local.

> 'bzr dpush' could also rebase all appropriate branches in the repository. It
> is a bit more work to find them, because we don't collect them side-by-side. I
> also would guess that git repos don't tend to accumulate as many branches. I
> don't know for sure, but I know my personal bzr repo has 200+ feature branches
> in it. And certainly doing "git branch" to list all the branches isn't very
> useful when it is multiple-screens long.
I really don't think this would be a viable solution - it doesn't
scale, annoys people and would be hellish to implement.

> > Hopefully, the above is true, accurate and even correct :-)

> > I consider the problem you highlight above to be more or less a blocker
> > to use of Bazaar as a Subversion client where the Subversion repository
> > is the master copy.  Where there is only ever one branch used there is
> > no problem -- I know I am doing this every day.  However this is such a
> > sever restriction of workflow, especially in the general Bazaar context,
> > that it should be treated as a blocker.

> I know at one point, Jelmer tried to have 'bzr commit' in a bzr branch bound
> to an SVN repository do the commit on the SVN repository first, and then
> effectively do a 'pull' into the local repository. (For normal bzr branches,
> you do the commit locally, and then wait to update your local branch tip until
> it successfully transfers to the master repository.)

> I wonder if this would solve some of the issues as well. You still have some
> issues about a dangling merge revision_id.
I never persued that further - Bazaar specifies a lot of
properties anyway that I have to store and that therefore have to be stored
in svn file properties, and the whole reason of having dpush is to be able to not 
use any custom file properties.

> > NB  If you store the Bazaar branch in the Subversion repository, i.e.
> > don't use dpush, use push, then none of the problems happen, arbitrary
> > branching is possible.  The downside of this is that if the Subversion
> > repository uses svnlook or certain other commit mail hooks, then you get
> > increasing and arbitrarily large commit emails -- but this has been the
> > topic of previous exchanges on this list.

> I also don't specifically know why bzr-svn has to create an ever-increasing
> list on the remote side. I believe Jelmer does it for performance. The svn
> protocol doesn't make it easy to ask "give me all values for this node over
> history", rather you have to keep probing it repeatedly. So instead, Jelmer
> decided to make the "current" value be the full list over history. And it
> seems that 'svnlook' doesn't do deltas for properties, and thus emits the
> whole property for every commit.

Yep, that's it exactly :-)

Cheers,

Jelmer
-- 



More information about the bazaar mailing list