Stefan Küng wrote:
> Don't forget to assign the issue to yourself
Done.
> One thing we have to discuss though is how we should handle this. Right
> now, trunk is for the upcoming 1.4.0 release. We have to create a new
> branch for this. Question is now what the branch would be for: 1.4.x or
> 1.5.0. If the branch would be for 1.5.0, then we'd have a lot of merging
> to do from trunk to 1.5.0 to keep it in sync until we branch for 1.4.x.
> If the branch is for 1.4.x, then we have to merge a lot of fixes from
> trunk to it.
I will create the feature branch from /trunk@HEAD. As of today,
there seems to be no integration with TortoiseProc until late this
year. At that point of time, we should have an idea of when 1.5.0
might be released and whether log caching will be part of it.
Therefore, merging will be no issue until we have a far better basis
for decision making. BTW, I am quite accustomed to large and complex
merges (last Friday: 6000 revs branch back into /trunk, 8500 file changes)
My current plan:
(I) Initial Design
* use cases, requirements, big picture design
* storage layer design
(efficient in time & space, sufficiently generic / extensible)
* in-memory representation design
(efficient in time & space)
* basic query and update design
(check use-cases against data structure design)
(II) Data Layer
* write some code & design docs
* write a basic CLI
* add XML I/O
* finish implementation and test it
(III) Query Layer
* implement query functions
* add CLI support for queries
* finish implementation and test it
* add log query API similar to SVN
(IV) Repository connection
* implement incremental update and replace
* add connection to SVN repos layer (i.e. actually query logs through SVN)
* extend CLI support to optionally trigger SVN queries
* finish implementation and test it
(V) Integration
* add a log source abstraction to TortoiseProc
* add log cache as 2nd log source
* test and fix query layer API
It may give you the impression of over-engineering. But thinking
about it, I quickly realized that this feature is particularly helpful
for "extreme" use cases (like all sorts of statistics, QA etc.) Therefore,
I go for a terse, pre-processed data structure.
-- Stefan^2.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Jun 25 16:47:36 2006