Hi, Marc. It's been a while since I've heard from you.
I cannot ignore this recent uptick in interest in improving SJ. Timo just started working on these GUI improvement and I could not be happier about it. And at the same time Brian Allen is at work on the long-awaited Eclipse plugin. Let's all give Brian a hard time until the plugin is finished!
Nice to have you back!
And now Marc wants to get into the game. Well, it certainly is past time for a new release cycle.
The thing is, I remain very busy. But I've balanced SJ with other personal projects before, so I should be able to do it again. And this time, it looks like I won't be coding it all by my lonesome self. So let's do it!
I don't want to set up an issues tracking system, so if someone wants to take the lead on that, you have my blessing. Same with a wiki. I can give someone shell access to the sourcejammer.org space on SF if we can host these things there.
OK I will try to have a look at this with Atlassian, to see if they offer any hosting. It would be nice if we didn't have to worry about that part.
Other than that, let's put together a list of top priorities and a plan.[snip]
Here are my major hopes for a new SJ release cycle:
1) More integration with IDEs. Brian is working on Eclipse. I'm thinking of taking a look at
JEdit. 2) Generate activity reports.
3) Multi-language support server-side.
4) Full text searching using Lucene.
5) Modify how branches are handled (I roughly scoped this out in a long ago post to this list).
6) Concurrent versioning.
7) Folder-level security.
I think 6 and 7 will slip to a future release. I'd be very interested to hear what's on everyone else's wish list.
Things that would be nice...
1) Ability to "Find" files under a folder using search patterns (i.e. mysource*.java) and view the resulting list, and then have options to apply like "check out", "move", "delete", "get" etc - so you can do "cross axis" views of the directory tree - we have projects where we have to do into lots of different folders to select the same file (same name) to check them out etc.
This could possibly be implemented very easily with XPath in the server, although I can't recall what if any "wildcard" expressions XPath can support when selecting values.
2) Optimize the workings/data structure (I don't know their precise details yet) so that it is much faster. There's no way it should be this slow, even with SOAP. We need to look at minimizing the number of SOAP transactions, and maybe use a servlet to handle the download/upload of files in binary format instead of munging everything into XML which I am sure produces lots of garbage and wastes a lot of CPU at both ends of the link.
3) IDEA 4/5 Plugin - this might be possible if they've improved their API now. I previously looked at it and coupled with lack of documentation for the SJ client code and their lack of documentation and rigid CVS-based API, it was a nightmare!
4) A view where you can (quickly) see all the files other users have checked out (crucial in an "exclusive lock" VCS system IMO), flattened.
5) Show labels in a separate list view, and maybe not store them in the same directory.
6) Flexible plugin architecture. IMO SJ should stay small at its core - but we need a plugin framework for adding components that do neat stuff. A simple event interface should do it, but it may require some new "easier to use" data structures to be passed out.
It would help immensely with any work we (or others) might do if you could first produce some kind of document explaining how SJ works vis the XML and filesystem. This is fundamental to understanding how to do anything with it, and can take a long time to work out from the code.
Also, I'd be curious to hear how others see the future of SourceJammer. It's strength, in many ways, I think, is that it's a "little" source control system. Easy to install and administer. Simple to use. I'm tempted to see it growing down the road into a feature-rich competitor to Subversion. But on the other hand, perhaps that's something SJ should never become because it might lose it's niche.
Possibly, but probably not. If it's great software it's great software. The killer feature for me is the easy GUI. If you keep that you can't lose IMO - from what I can tell Subversion is suffering quite badly because it has no good GUI. The things I have seen look awful, and from the WinCVS/JCVS family, which is not a good heritage :)
It would be neat to have a very rich branch and merging functionality where you could create a sandbox for each developer and a system of promotion from sandbox to development to production branches. But maybe that's the wrong way to go. I definitely would like so hear some thoughts.
I'm really not all there with the branching concepts yet. We try to avoid branches as much as poss, as surely you are inevitably left with a CVS-type "have to manually merge it" situation which is ugly :)
Also, Marc, what are the bugs that are causing you problems?
I mentioned some in my last email. The Daylight Savings Time problem, zombied lock files on server, list view freakout, I think there was another...
Cheers
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ SourceJammer-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sourcejammer-devel
