> Tres Seaver wrote:
> > Christian Theune wrote:
> >> On 06/03/2010 05:05 AM, Tres Seaver wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>> Tres Seaver wrote:
> >>>> Log message for revision 112936:
> >>>> Add tag 3.4.2
> >>>> Changed:
> >>>> A zope.applicationcontrol/tags/3.4.2/
> >>> I have *no* idea what these messages are about. I was certainly not
> >>> tagging releases for zope.applicationcontrol today.
> >> Worst case: someone has your key?
> > Not too likely -- more likely some weird bzr-svn bug, as the new tags
> > are showing up in projects where I had been merging bzr branches with
> > janitorial cleanups: they appear immediately after the "real" commit.
> > I have switched over to avoiding 'bzr merge' for now, which seems to
> > have stopped the faux tag creation.
> I have a theory, but am not sure how to test it: I think that I recall
> for both affected projects (zope.applicationcontrol,
> zope.cachedescriptors), I mistakenly attempted to merge a bzr branch for
> a completely different project. When the merge failed, it left my local
> branch apparently clean, but it might have messed up the heuristics /
> bookkeeping which bzr-svn uses to infer tags for the project.
Consider using shared repositories with a fresh branch for each merge:
Basically, you do something like this:
bzr init-repo zope.applicationcontrol --format=rich-root-pack #last I
checked, bzr-svn liked this format, you can also --format=svn
bzr branch lp:zope.applicationcontrol #bzr looks for .bzr in ., which
tells it there is a shared storage
What this does is allow you to have multiple local branches of something
without wasting full repo storage on each one. This func goes back at least
to BitKeeper and may be able to use hardlinks to further reduce storage
redundancy, though that can lead to pain, suffering, anger, etc..
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -