Re: Future of git-plugin

36 views
Skip to first unread message

Remy Blank

unread,
Mar 3, 2012, 11:23:57 AM3/3/12
to Peter Suter, Christian Boos, Herbert Valerio Riedel, trac...@googlegroups.com
(CC: to trac-dev, we want to have such discussions in public.)

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

signature.asc

Peter Suter

unread,
Mar 3, 2012, 12:28:48 PM3/3/12
to trac...@googlegroups.com, Herbert Valerio Riedel
On 03.03.2012 10:48, Herbert Valerio Riedel wrote:
> Just wondering, isn't the mercurial plugin self-hosted on t.e.o as a
> mercurial repo?

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

[1] https://github.com/edgewall/trac

Peter Suter

unread,
Mar 3, 2012, 12:51:37 PM3/3/12
to trac...@googlegroups.com, Herbert Valerio Riedel
On 03.03.2012 17:23, Remy Blank wrote:
> (CC: to trac-dev, we want to have such discussions in public.)

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

Herbert Valerio Riedel

unread,
Mar 3, 2012, 1:09:42 PM3/3/12
to Peter Suter, trac...@googlegroups.com
Peter Suter <pets...@gmail.com> writes:

...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
--

Remy Blank

unread,
Mar 3, 2012, 1:12:05 PM3/3/12
to trac...@googlegroups.com
Peter Suter wrote:
> 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`.

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

signature.asc

Herbert Valerio Riedel

unread,
Mar 3, 2012, 1:19:23 PM3/3/12
to trac...@googlegroups.com, Peter Suter, Christian Boos

> Peter Suter wrote:
>> 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:

>> == 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

--

Reply all
Reply to author
Forward
0 new messages