David Abrahams wrote:
> on Wed Nov 21 2007, Thomas Moschny wrote:
>>> * Vastly improved versioncontrol subsystem (see VcRefactoring)
>> Naturally [*], I am +1 for this. While the majority of people use trac
>> together with subversion repositories, importance of other version
>> systems increases. I don't think support for those should be postponed
>> a 1.0 release.
>> Main points are:
>> - better support for vc systems with dag-like revision and file history
> That'll become even more important when SVN 1.5 comes out (it's
> supposed to be imminent).
I think you're referring to the new merge tracking features of 1.5. By
following Subversion-devel, I can tell you that it's not even clear at
this point what kind of merge support should be expected in 1.5 and what
will be deferred to 1.6 or even later. Speaking from a Trac-centric
p.o.v. I would rather like to see memory, performance and stability
improvements (not to mention the new ctypes bindings!) instead of
limited merge features...
That being said, the support for the future Subversion merge tracking
features will probably be doable without the need for any big change in
the API. I think all we need are some special property renderers, much
like it's already done for e.g. the svn:externals in 0.11.
The changes needed for supporting fully the dag-like revision systems
are much more challenging, and that's why it's harder to assign a
milestone for those (#1492 - support for non-linear changeset sequences
for monotone-like VCS). Targeting 1.0 seems fair, it can always be put
back to an earlier milestone like 0.13 once the code is there. Deferring
it to 2.0 has this bad "blue sky" connotation, though it's probably in
this area that alien technology would be the most beneficial for us ;-)
The single small incremental API change I want to make for 0.12 at this
point is the one documented in #4900 (see
As a side note, the support for merging in Subversion is probably best
found /outside/ of Subversion itself. Mercurial or Git can be used
locally to sync the changes from the t.e.o. trunk, merge the upstream
changesets in feature or bug fixes branches, and merge those branches
back to trunk, with full history if needed.
See for example [6177:6182], the implementation for div/span wiki
processors, which was developed in a mercurial clone of trunk and
maintained there as a patch queue until it was ready to push to t.e.o. A
similar workflow can probably be achieved with git, git-svn and
git-rebase as well.
You received this message because you are subscribed to the Google Groups
"Trac Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en