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 trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---