Craig I just want to warn you that the patch for the Upload and Attachment functionality included wiki.css which it really should not have. I hope this does not cause any trouble.
John Davidson On 7/25/07, Craig Andera <[EMAIL PROTECTED]> wrote: > > 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 > ------------------------------------------------------------------------- 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
