Peter Suter wrote:
> I think it would be great if we could include this plugin in Trac.
> (Would be a nice "bonus" for Trac 1.0 :)
Yes, that would be awesome.
> While I'm not much of a git user, I'd like to know if there's anything I
> could do to help. I'd (naively) expect the next steps are something like:
>
> * Commit that snapshot to SVN to
> https://svn.edgewall.org/repos/trac/plugins/0.13/git-plugin/ or
> https://svn.edgewall.org/repos/trac/trunk/tracopt/versioncontrol/git/
I'm not sure either what the best location would be. The Mercurial
plugin has to be separate from Trac itself due to the license, but this
wouldn't need to be the case for the Git plugin. So "tracopt" would be
the simplest for our users, and they would have it installed already and
would only need to enable it.
If we do that, we could also move `svn_fs.py` out of
`trac.versioncontrol` and into `tracopt.versioncontrol`, for consistency.
Just make sure you do each step in a separate changeset, so that we can
easily roll back one or the other if necessary. In particular, the
initial import should add the files from the git repository unchanged,
so that all diffs against the original are explicitly visible.
> * Adjust the license file headers somehow? (future27.py has a strange one)
> * Review and cleanup according to [[TracDev/CodingStyle]]
This should probably include moving the few existing unit tests in
`future27.py` out of the `__main__` section of that file into
`tests/future27.py` and having it called as part of the normal unit tests.
> * Setup a git mirror
If we move it to `tracopt`, this wouldn't be necessary.
> == Wiki
> * Create a page at http://trac.edgewall.org/wiki/TracGit or GitPlugin to
> document this.
>
> == Tickets
> * Create a ticket component 'plugin/git' on t.e.o.
> * Migrate existing trac-hacks tickets to t.e.o. somehow?
If there are many tickets, we could find a way to import them
automatically. Otherwise, just copy / paste the relevant ones, and close
the rest.
> Maybe we should open a ticket for this migration itself?
Yes, please do.
Thanks for tackling this!
-- Remy
I don't think so. Would be nice to have though.
But as Remy pointed out, the Git plugin would be included in the Trac
GitHub mirror [1] automatically (if we include it under 'tracopt'
instead of under 'plugins' in SVN).
--
Peter
Right, thanks!
> This should probably include moving the few existing unit tests in
> `future27.py` out of the `__main__` section of that file into
> `tests/future27.py` and having it called as part of the normal unit
tests.
I'm wondering, would it be best to drop `future27.py` entirely? It only
defines (and tests) `namedtuple`, which is only used once to define
`Storage.RevCache`. It seems it would be easier to define:
{{{
class RevCache(object):
def __init__(self, youngest_rev, oldest_rev, rev_dict, tag_set,
srev_dict, branch_dict):
self.youngest_rev = youngest_rev
self.oldest_rev = oldest_rev
self.rev_dict = rev_dict
self.tag_set = tag_set
self.srev_dict = srev_dict
self.branch_dict = branch_dict
def __iter__(self):
yield self.youngest_rev
yield self.oldest_rev
yield self.rev_dict
yield self.tag_set
yield self.srev_dict
yield self.branch_dict
}}}
Or is there more to it?
This would also eliminate the license question. (I.e.: Can we commit a
file that says "# Copyright (C) 2001-2010 Python Software Foundation;
All Rights Reserved"?)
> If there are many tickets, we could find a way to import them
> automatically. Otherwise, just copy / paste the relevant ones, and close
> the rest.
There are currently 40 open tickets. At first glance I think we can drop
these:
#8393 Outdated git version
#8102 Python 2.4 only
#6398 0.11 branch only
#7381 Permission problem
#9134 Permission problem
#8844 Permission problem
#9641 Permission problem
#8465 Duplicate of #8682
#8473 Duplicate of #8682
#3888 Duplicate of #6216
#9581 Duplicate of #9560
#7665 No feedback
Which leaves, roughly categorized:
#8944 (unicode, `git_fs_encoding` configuration issue?)
#8087 (unicode, `git_fs_encoding` configuration issue?)
#8639 (linefeeds, PATCH)
#2633 (Feature request: branches)
#7860 (Feature request: branches)
#8522 (Feature request: branches, PATCH)
#2685 (changeset links, Fixed?)
#8937 (changeset links)
#6216 (changeset links)
#8658 (changeset links)
#8354 (changeset links, PATCH)
#9657 (cygwin, PATCH)
#8016 (cache)
#4505 (cache)
#8880 (submodules)
#3842 (submodules, NoneType)
#9552 (NoneType, Ubuntu)
#8682 (Could not retrieve GIT version / NoneType, Ubuntu / OpenSUSE)
#4227 (Could not retrieve GIT version / subprocess, Ubuntu / OpenSUSE)
#9560 (subprocess, with statement, PATCH)
#9646 (subprocess)
#9778 (subprocess)
#8401 (subprocess, not enough info?)
#8260 (bare repo, gitolite)
#9879 (Bitten)
#746 (performance)
#4318 (Documentation)
#8456 (?)
Probably we can merge some more of these as duplicates.
>> Maybe we should open a ticket for this migration itself?
>
> Yes, please do.
Done: #10594
--
Peter
...one property of namedtuple() to keep in mind is that it doesn't
mutate the RevCache instance in-place but always creates a new one,
i.e. namedtuple provides a /persistent/ data-structure. Moreover,
namedtuple() also uses __slots__ internally as an optimization, which
will become noticeable the larger the revision-cache gets.
However, you could just take the Python code that namedtuple generates
(which I'm /assuming/ is not covered by the Python std-lib copyright)
and throw away the namedtuple()-code-generator... then you should be on
the safe side wrt to bug-compatibility.
hth,
hvr
--
I haven't looked at the code closely, but if it's indeed the only use
case, then yes, defining the class explicitly would be even better.
> Which leaves, roughly categorized:
(... snip list ...)
> Probably we can merge some more of these as duplicates.
That's probably not enough to warrant writing an exporter and importer,
so I guess some copy / pasting of ticket descriptions is in order. Make
sure to reference the original ticket in the description of each new
one, so you don't need to copy the comments.
-- Remy
>> == Wiki
>> * Create a page at http://trac.edgewall.org/wiki/TracGit or GitPlugin to
>> document this.
...btw, someone should update http://trac-hacks.org/wiki/GitPlugin
to point/redirect to that new official wiki page when it's ready
--