Patches, Trac, VCS etc.
shane at isc.org
Tue Jul 7 08:43:36 UTC 2009
On Tue, 2009-07-07 at 02:17 +0300, Faidon Liambotis wrote:
> BTW, is there a particular reason why cruft-cleanout hasn't been merged
> back to trunk yet? It seems like the consensus is that a cleaned up tree
> is the way to go and is the one that will be transformed to 5.0.
IIRC it's still under fairly active development by Nick, and the idea is
to merge it into trunk relatively soon.
> Also, let me apologise for the irregular way of posting my patches.
> I've come to understand that posting them through Trac seems to be the
> status quo around here. Besides some trouble I had on reaching
> irrtoolset's Trac, I think it's wrong to use a bug tracker as a
> patch-handling system. Don't get me wrong, I like Trac, but for the
> purproses it was intended to be used, which don't include, IMHO,
> (ab)using it as a VCS.
I'm not an expert on bug tracking or patch handling systems, and to be
honest I don't know what VCS is. Version Control System, I guess?
As far as I know, Trac is a one-stop-shop for developers, and includes a
Wiki, ticketing system, and hooks into a revision control system. It
defaults to using Subversion for the revision control.
> In the DVCS-era, I could commit those in a branch of mine and then send
> a pull request (e.g. to Nick) who could then cherry-pick them and/or
> merge them. Well, I could commit them now in a separate branch in
> Subversion but a) it's a pain in the arse to do merges with it, b)
> someone would need to actually trust me and grant me commit access,
> which is an unnecessary step in the DVCS-world...
> So, have you considered switching e.g. to git or mercurial? :-)
> I've been working with a git-svn tree to manage the patches I sent.
> Unfortunately, the tree's history is cluttered because of the cvs->svn
> conversion and much of it has been lost (e.g. I'm unable to do a proper
> bisect) but it still proved quite useful.
I guess DVCS is distributed version control system.
Trac supports git and mercurial as the underlying revision control
system. As I understand it, the advantage of such a system is that it
allows developers do to a lot of work before merging into the main
system. This is useful in environments where people want to make
proprietary changes, or where their changes are unlikely to be accepted
by the main developers (like Linux realtime patches).
I don't think that the IRRToolSet actually matches any of the cases
where a DVCS makes sense. I'm not opposed to using something like git or
mercurial, and if there is an easy way to convert from Subversion to git
I guess there's no special reason not to do it.
> Anyway, I think I'm too new around here to mandate the workflows, I'm
> just throwing a suggestion based on previous experience.
> If you'd prefer to have those patches on Trac, just say so and I'll go
> through the trouble.
I'm not sure what you mean by saying "have those patches on Trac". I
think having a ticket with information that explains the problem and the
solution are very useful. This information often makes no sense when put
into the source code itself. The actual patch can be a separate diff
file, or a Subversion branch, or just a few lines of code in the ticket
or an e-mail.
Are you asking for the ability for the patch to be a direct git pull
from your repository? I'd rather have all the patches somewhere
associated directly with the IRRToolSet, so that we can see it in the
distant future (although maybe Trac git is smart enough to keep a local
copy of such things).
More information about the irrtoolset