Hi all, While we are on this topic, the best tool I have come across for Software Configuration Management is Perforce. (www.perforce.com)
Its cross-platform and free for Open Source projects. It also integrates with bug tracking software like Bugzilla. I don't really know what the ASF policy is regarding CVS, but since someone did mention Subversion, I thought I would mention this one as well. Thanks, Serge ----- Original Message ----- From: "Serge Knystautas" <[EMAIL PROTECTED]> To: "James Developers List" <[EMAIL PROTECTED]> Sent: Monday, December 30, 2002 12:51 AM Subject: Re: Specific Steps to Release > Danny Angus wrote: > >>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) > > <cvs-tangent> > 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> > > > 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. > > 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... > - 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
