Sat Dec 17 10:22:16 PST 2005 Brendan Cully <[EMAIL PROTECTED]>
* Get tags from git sources
Sat Dec 17 17:17:43 PST 2005 Brendan Cully <[EMAIL PROTECTED]>
* Use git-rev-list to read tags
The previous tag reading code only understood lightweight tags. This
uses git-rev-list to read real tag objects as well. It might be a good
idea to cache tag info (based on a stat of the file in refs/tags) per
run, to avoid recomputing the same information at every changeset.
New patches:
[Get tags from git sources
Brendan Cully <[EMAIL PROTECTED]>**20051217182216] {
hunk ./vcpx/git.py 136
- return Changeset(revision, date, user, message, entries)
+ # Brute-force tag search
+ from os.path import join, isdir
+ from os import listdir
+
+ tags = None
+ tagdir = join(self.basedir, '.git', 'refs', 'tags')
+ try:
+ alltags = [(name, join(tagdir, name)) for name in listdir(tagdir)]
+ tags = [tag[0] for tag in alltags
+ if file(tag[1]).read().strip() == revision]
+ except OSError:
+ # No tag dir
+ pass
+
+ return Changeset(revision, date, user, message, entries, tags=tags)
}
[Use git-rev-list to read tags
Brendan Cully <[EMAIL PROTECTED]>**20051218011743
The previous tag reading code only understood lightweight tags. This
uses git-rev-list to read real tag objects as well. It might be a good
idea to cache tag info (based on a stat of the file in refs/tags) per
run, to avoid recomputing the same information at every changeset.
] {
hunk ./vcpx/git.py 140
- tags = None
+ tags = []
hunk ./vcpx/git.py 143
- alltags = [(name, join(tagdir, name)) for name in listdir(tagdir)]
- tags = [tag[0] for tag in alltags
- if file(tag[1]).read().strip() == revision]
+ for tag in listdir(tagdir):
+ # Consider caching stat info per tailor run
+ tagrev = self._tryCommand(['rev-list', '--max-count=1', tag])[0]
+ if (tagrev == revision):
+ tags.append(tag)
}
Context:
[Small bzr API change in 0.7
Ivan Vilata i Balaguer <[EMAIL PROTECTED]>**20051214185429
I would like to point out an small API change in the Bazaar-NG
development version (0.7pre): the ``rename_one()`` method does no
longer belong to ``Branch``, but to ``WorkingTree`` (see
http://bazaar-ng.org/bzr/bzr.dev/NEWS). This makes Tailor crash under
some renames.
]
[Intercept and emit warning when using the BazaarNG backend with Python <2.4.
[EMAIL PROTECTED]
[use lelit method to distinguish between 2.3 Set and 2.4 set
R.Ghetta <[EMAIL PROTECTED]>**20051203100429]
[set() built-in is available only on python-2.4 Use the sets module instead.
R.Ghetta <[EMAIL PROTECTED]>**20051203065932]
[Use bzr.dev new smart_add_tree() in place of smart_add_branch()
[EMAIL PROTECTED]
[apparently svn backend missed the 'Replacing' case on commit
R.Ghetta <[EMAIL PROTECTED]>**20051204090751]
[add target dir of a file rename to implicit_dirs
R.Ghetta <[EMAIL PROTECTED]>**20051204090719]
[Use the configured CVS repository instead the default one
TK Soh <[EMAIL PROTECTED]>**20051206084923]
[Handle '.' as module under svn, replacing it with '/'
[EMAIL PROTECTED]
[bzr WorkingTree fixes
Bart Teeuwisse <[EMAIL PROTECTED]>**20051128210737]
[Strip ending new line and prepend the basedir to the boring file name
[EMAIL PROTECTED]
[Possibly use the preferred boring file
[EMAIL PROTECTED]
[monotone passphrase must now be specified. Also added an optional custom_lua parameter
R.Ghetta <[EMAIL PROTECTED]>**20051123064020]
[Fix tkt 17 (let svn do mv itself instead of add/remove)
Brendan Cully <[EMAIL PROTECTED]>**20051120053823
The problem described in ticket 17 arises because upstream has already
relocated the renamed directory, including the .svn metadir
inside. This metadata directory causes svn to refuse to add a path
that it believes is already under version control. But that metadir
now disagrees with the working directory about where it exists in the
file system.
We have a couple of choices: either put the directory back if possible
and let svn do the merge on its own, or remove the .svn entry from the
new directory and all its subdirectories. I like the first choice, not
just because it's a little easier, but also because it preserves file
history. The current implementation notes that svn mv is equal to svn
cp+rm, but doesn't actually do cp+rm. Instead it does rm+add, which
isn't equivalent.
I had to add --force to the mv operation to handle the case where the
renamed entry or content underneath it had been changed in the same commit.
]
[Use the encoding error policy specified on the repository
[EMAIL PROTECTED]
[Fix directory renames in hglib target
Brendan Cully <[EMAIL PROTECTED]>**20051120035559
The last rename patch failed to account for the fact that mercurial only
understands files, not directories. This fixes the logic in the new
_getCommitEntries method and also corrects a bug in renamePathname that
ate too much of the directory prefix, by using os.path.split and join
instead of guessing at the length of the separator.
]
[commit both old and new names of renamed files in hglib
Brendan Cully <[EMAIL PROTECTED]>**20051120021905]
[Use the new encode facility of the Repository
[EMAIL PROTECTED]
[New option `encoding-errors-policy` and centralization of encode() on Repository
[EMAIL PROTECTED]
[Mention the lookup mechanism for the configuration options
[EMAIL PROTECTED]
[M-x whitespace-cleanup
[EMAIL PROTECTED]
[git source support
Brendan Cully <[EMAIL PROTECTED]>**20051117184454
This adds support for git sources. It does not provide tags or detect
conflicts in the working directory.
]
[Test for old-style darcs date format
[EMAIL PROTECTED]
[Don't crash on empty darcs changesets
Brendan Cully <[EMAIL PROTECTED]>**20051117035753
The old guard code "if changeset" would never fail because the
expression being tested is a generator, which always exists even if it
never yields anything. Guard on the StopIteration exception instead.
]
[Handle old-style darcs date format
Brendan Cully <[EMAIL PROTECTED]>**20051117035425
Older darcs patches appear to keep the date in the form
Sun Oct 20 20:10:04 EDT 2002 rather than the current
20021020201004. This patch tries to parse the date as the old format
if it fails to read it as the new. NOTE: This older patch format also
calculates the hash from the date in the recorder's time zone, but
darcs pull uses the puller's time zone, so it may not calculate the
correct hash of the patch. Perhaps it's safer to just throw an
exception if the date isn't in the current format?
]
[Don't version .hgtags when pulling from mercurial
Brendan Cully <[EMAIL PROTECTED]>**20051115100427
It's only useful to mercurial repositories, but if by chance we happen to be
making a round trip back to mercurial, the file will be wrong anyway because
the changesets are all new.
]
[Use UTC0 not UTC to force a neutral timezone
[EMAIL PROTECTED]
[Add tailor-created files to Monotone's list of ignored files
"Neil Conway <[EMAIL PROTECTED]>"**20051116194227
This could be done by installing a new ignore_file Lua hook, or adding
entries to the .mt-ignore file (which is read by the default ignore_file
hook). I chose the latter, as it is simpler. It breaks if you install
a custom ignore_file hook that doesn't read .mt-ignore, but if you do
that then presumably you know what you're doing...
]
[Don't apply duplicate tags to mercurial targets
Brendan Cully <[EMAIL PROTECTED]>**20051116052626
I just noticed that a CVS source will replay all of the tags that apply
to HEAD on every run. This teaches mercurial to filter out equivalent tags
(by checking whether they already exist in the commit history up to the last
non-tag commit).
]
[Add tag support to mercurial target
Brendan Cully <[EMAIL PROTECTED]>**20051115100534]
[Add tag support to git target
Brendan Cully <[EMAIL PROTECTED]>**20051115075709]
[Sanitize CVS tag names
Brendan Cully <[EMAIL PROTECTED]>**20051115073722
CVS tag names are more restrictive than those of other repositories. This patch
downcodes them where necessary.
]
[Fix mercurial source deletion detection
Brendan Cully <[EMAIL PROTECTED]>**20051115070747
The original mercurial delete logic would find any unchanged file in a
changeset to be deleted. This horrible bug was mitigated by the fact that
I had forgotten to actually add DELETED changeset entries to the changeset.
]
[Pick up tags from mercurial sources
Brendan Cully <[EMAIL PROTECTED]>**20051115054848
Tailor appears to only be able to tag the current revision, so this patch
silently drops any retroactive tags. It might be worth expanding the tag
object with the notion of author, tag date and files tagged (the first two
are readily available but not passed on in _tag()).
]
[give -b flag for cvs trunk
[EMAIL PROTECTED]
[Create the info dir that contains the ignore file if it does not exist
[EMAIL PROTECTED]
[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:
f3fdde49deeb8c8e78fc53baaf2222d459ec294f
_______________________________________________
Tailor mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/tailor
