Hi again. There may be some overlap with my last response, but I'll try to address all of Marc's comments here.
> > 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. This is definitely my top desire. I was thinking that Lucene might be helpful, so we could do full-text searching. Maybe that would be overkill, but on the first pass I'd like to not only have find by file name w/ wildcards. I'd also like to include checkout status, edit date, author, and so on. And, yes, the idea would be for this to be a complete view of SJ files that would layer on top of the current file table. You should be able to act on files in this view the same as you do in the regular file view. And, jumping ahead, I'd like to develop this whole thing with plugins. This, in fact, was the main reason I started on the 2.1.1 client branch--to create a framework whereby you could plug in a new file view or some other view and still have access to all of the SJ actions, and create your own actions as well. > > 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. > See my coments in the previous message. Managing file upload/download outside of soap might have promise, but I worry about complicating things by requiring other ports to be open or anything like that. First I'd like to see how much we get from speeding up the xml parsing and trying different SOAP engines. > 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! RE: Nightmare. I heard that. The SJ "simple api" could definitely use some better documentation. It also obviously needs more testing, but we're starting to get there with Brian's Eclipse plugin. > > 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. Quickly is the key. I think the event-logger server-side plugin might be able to help us out with this one. > > 5) Show labels in a separate list view, and maybe not store them in the > same directory. > I'd like to make this an option. Actually, I'd like to continue storing them in the folder in the SJ archive, but perhaps hide this implementation from the user and maybe expose labels in the Project properties dialog I discussed in the previous message. This might fit in with the new branch architecture I have in mind as well. > 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. The simple event interface already exists on the server side. There's one on the client side as well, but it is a kluge. 2.1.1 client addresses this issue, but, as I've said before, it's been sitting in an unfinished and untested stated gathering dust for over a year. > > 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. I hear you. I think this is the top SJ priority for me. I'll see what I can come up with over the next week or so. > > > 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 :) > Good to know that. As the developer of SJ, it's hard for me to really know what people like about it. It's my baby, so I like everything. Easy-to-use GUI is definitely something lacking IMO in the CVS family of products. > > 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 :) > Yes, this is the sort of thing I fear as well and why I have not really using branching/merging myself. I understand that ClearCase handles this sort of thing very well and that this might be the model to immulate. Still, managing merge conflicts will be a pain, no matter what you do. One outstanding issue on this front (and the concurrent checkout front) is a 3-way diff algorithm for Java that works. Last I checked, there was not an open source 3-way diff api anywhere. Maybe this has changed? Regardless, a friend suggested that I simply outsource the whole 3-way diff issue by allowing SJ users to specify the merge conflict tool they want to use. Aparantly there are visual merge conflict tools out there already so we might not even have to build our own at all. If that's the case, then concurrent versioning becomes very easy to implement. --Rob > > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------- 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
