David Abrahams wrote: > on Wed Nov 21 2007, Thomas Moschny <thomas.moschny-AT-gmx.de> 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 control >> systems increases. I don't think support for those should be postponed after >> 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 http://trac.edgewall.org/ticket/4900#comment:4). 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. -- Christian --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
