Danny Angus wrote:
<cvs-tangent>I would expect that we'd want to be able to easily work with either set of code. Again, I know how I'd do this with SourceSafe, but CVS is a pretty primitive beast (I hope that Subversion is smarter about code sharing).You can, you can check out both brances side by side and/or choose the brach of each file you are working on Branching has the added advantage of allowing merges and diffs of the file between the two (or more) versions (branch and HEAD)
I guess CVS is primitive, but mostly due to a different philosophy to code management and locking. It used to be primarily open source projects using it (compared to PVCS and sourcesafe for commercial projects), but I'm now looking at all MS shops moving towards CVS (and Ant). The Visual Studio integration is tough to move away from, but CVS seems to have gotten the underlying theory to code management and locking right. Subversion for the moment doesn't really have any plans to exceed or change CVS functionality... they want to support *moves* (the biggest CVS deficiency) and maybe binary diffs, but then just have it in Java and over HTTP for future extensibility options.
</cvs-tangent>
Yeah, I think a branch is fine. To give you an idea of some of what I'd like to get started on the 3.0 branch...Forking is simpler but I don't think "root" would approve, the policy is to encourage us to maintain everything within our module, so we could conceivably move to a structure like: jakarta-james/ -james/ --2.1/ --3.0/ -/mailet --2/ --3/ but to be frank I (personally) think a branch would do.
- replace mordred with dbcp
- finish off the changes I'd made to load mailets/matchers/supporting classes from apps/james/classes & apps/james/lib.
- sort out the SMTP handler buffering (might do this on the 2.1 branch as well)
Probably a few other things, nothing major or hotly debated features, but stuff that would reduce confidence in builds and slow future releases of the 2.1 branch.
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
