> I really think Craig should release the current codebase, less the > Attachment patch, as the Beta 2 now. I have been doing a lot with it > except for some WikiTalk programming that I wat to try and it is rock > solid for me.
OK, I'll do so at the earliest opportunity. Given the way things are going right now, that might not be immediately. > I would push to put the Attachment patch in a feature branch, except > for two reservations. > > First, I do not fully understand the additional load on the admin for > publishing a main and branch release. It's not that bad, although it's not trivial. We set up another branch, create another CCNET project (which is essentially a clone of the 2.0 bits) and off we go. We do have to remember to merge changes back and forth, but that's nothing terrible, although it tends to scare people for some reason. > Second, is the original codebase that does not meet current > programming standards. Is subversion better at managing signifact > re-ordering of code than WinMerge? If it is then there is really no > problem, otherwise code refactoring should occur in the trunk before > any changes are made in a branch. Well, I'm not sure what you mean by "managing" reordering. Any change to a file is a change. A bigger problem is renaming of files, which Subversion is actually pretty good about if devs remember to do a svn move instead of just deleting and adding. I'll admit I don't always move stuff myself, even when I should. Oh wait - I think I see what you mean. Yeah, Subversion isn't great at that. I don't know whether it's better or worse than WinMerge, but massive changes like that aren't exactly always seamless. But honestly, that's really just what happens when there's significant work in two branches. > I am unsure what interface Pascal is thinking of implementing for the > upload and attachment properties, but I am sure it will be easier for > him if he didn't have to deal with the interface in the pending > Attachment patch (even though the code is inactive in default state, > it is still part of the page, though in a hidden state). Perhaps > Pascal would also be willing to have a feature branch? > > > Craig failed to mention that the attachment patch currently has no > test code. I must emphasize that htis is a quick hack and the fact > that it would only exist in the core code for a short period of time > anyway, is another argument for putting it in a branch rather than the > trunk. It would also make it easier to respond to the attachment user > community (if there is one) without impacting the main community > adversely. The entire web app is essentially untested. We did have some rudimentary tests hacked together with a weird home-grown integration testing framework that we wrote ourselves, but unsurprisingly it broke and I never had time to figure out why. So now we only unit test, and the architecture of the web app precludes unit testing the web framework. Of course, ASP.NET itself makes that sort of a pain in the ass, but we *could* work around that if we wanted to. The good news is that the core has decent (but not great) coverage. The new stuff I wrote has coverage numbers in excess 90%, and overall the core is at about 64%. We still have some tests from 1.8 that haven't been refactored - that's an opportunity for someone to do good there. Of the rest, I'd say that Federation is probably the most in need of additional coverage - it's super important, a total mess, and has only 43% coverage. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
