Bruce Stephens <[EMAIL PROTECTED]> writes:

[...]

> I think the latter's what's wanted.  I guess 9 times out of 10 it
> makes no odds, since branches other than the trunk tend to be fairly
> inactive, CVS being so poor at merging.

I attach the little hack I did, which seems to work, so far.  Probably
I've missed things, and it has no tests, etc., so I'm in no way
suggesting it's an appropriate resolution.

New patches:

[give -b flag for cvs trunk
[EMAIL PROTECTED] {
hunk ./vcpx/cvs.py 568
+                if not branch:
+                    cmd.append("-b")
hunk ./vcpx/cvs.py 575
+            else:
+                cmd.append("-b")
}

Context:

[Fix a last-second BPB converting revision names.
Brendan Cully <[EMAIL PROTECTED]>**20051114030337] 
[Mercurial source support via hglib
Brendan Cully <[EMAIL PROTECTED]>**20051114022602] 
[git commit fixes (date, # at end of commit message)
Brendan Cully <[EMAIL PROTECTED]>**20051114022122
 
 As of at least git 0.99.9e, git refuses to parse timestamps with
 microseconds such as str(datetime) may emit. This patch uses strftime
 to force the format to something simpler.
 
 It also manually duplicates GIT_AUTHOR_* to GIT_COMMITTER_* so that
 cg-log produces output most similar to the source log.
 
 git-commit expects the commit message to end with a newline, so this
 patch adds one if it isn't already there.
] 
[Ensure str() doesn't get handed a unicode changeset
Brendan Cully <[EMAIL PROTECTED]>**20051114021851
 
 I don't do a lot of python, so I may be misdiagnosing this bug, but I
 get a UnicodeEncodeError at Tailorizer.applyable on the debug line
 when tailorizing a source with non-ascii log messages on a UTF-8
 terminal. It appears that str() expects a __str__ function it calls to
 return a plain (not unicode) string. Could possibly be an OS X issue.
 
 The particular test was tailorizing the bzr repository from bzr to git
 or hglib, with changeset messages apparently in macroman, on a UTF-8
 terminal. This problem is made more annoying by the fact that bzr no
 longer seems to be able to resume (_b undefined in the upgrade path).
] 
[Fix bzr incremental update
Brendan Cully <[EMAIL PROTECTED]>**20051114060007
 
 Incremental update in bzr isn't working: when tailor restarts it has no
 handle on the bzr branch object, and when it does a merge it doesn't
 make sure that it already has the changesets it needs. This patch
 introduces a getRepo method that gets a branch handle if there isn't one,
 and calls bzrlib.fetch.greedy_fetch to pull in all changesets before
 attempting to merge them.
] 
[Ignore the backup copy of the state file
[EMAIL PROTECTED] 
[Fix cut&paste error
[EMAIL PROTECTED] 
[TAG Version 0.9.19 (retag)
[EMAIL PROTECTED] 
Patch bundle hash:
88694f3d043091cc0b57f0b2b100a9e223c23776
_______________________________________________
Tailor mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/tailor

Reply via email to