Patches, Trac, VCS etc.
paravoid at debian.org
Wed Jul 8 13:31:48 UTC 2009
Shane Kerr wrote:
> 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?
> I guess DVCS is distributed version control system.
Right, that's what they mean. Sorry for the confusion, it was wrong for
me to assume that everyone here knows what I'm talking about, esp. out
of context :-)
> 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.
Right. Again, I have no problems with Trac whatsoever.
> 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).
No, not exactly. I wanted, for example, to do some work on the package
(these 10 patches I sent). It'd be extremely hard for me without a DVCS
to code such changes and produce split, self-contained and actually
readable diffs. My workflow has been basically "vi ...; git commit;
git-format-patch master..grnet; git-send-email 000*".
Also, such systems allow for very cheap branching and merging, extremely
useful for experimenting with new changes, such as the cruft cleanup branch.
> 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.
There's git-svn which I already use in parallel. You can even do SVN
commits with it, it's an almost-perfect SVN client implementation.
For a switch for the project, however, there's a steep learning curve,
especially with git (vs. mercurial, for exmaple).
So unless you, Nick and other contributors see the benefit yourselves, I
wouldn't push for such a change :-)
> 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.
I've documented all of my patches on my git commit log and, therefore,
on the body of the emails that I sent.
Would you like more information than I provided?
What would you like me to do with these? Attach them to separate Trac bugs?
> 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).
This is getting a bit off-topic, but with git you could pull my branch
without necessarily merging; I could then do merges and/or rebases to
keep up with development and you could cherry-pick or just merge my changes.
Believe me, my intention is not to fork and/or maintain an additional
patchset. I'd like to work with you and merge all of my changes in any
form that are desired. I've seen some irrtoolset forks out there and the
situation is quite messy.
It seems we're at a point that we can bring irrtoolset to a reasonable,
2009-era state and I'm interested in working for this :-)
More information about the irrtoolset