On Tue, Mar 31, 2009 at 8:17 PM, DrunkenMonk <[email protected]> wrote: > > a) multiple users editing the same page (file) at the same time, must > be automatically handled unless they are editing the exact same part > of the file, at which point the last person to commit the changes > would be allowed to make further changes based on both edits. We would > need to write an "edit" action that uses this functionality. Not hard. > Something like: > edit -> check out a copy of the file to edit. There may be better ways > to handle this, but I am unsure. Thinking about it at 2 in the morning > it seems that every user editing a page would need their own temporary > folder, at least at the point of commiting the edit. > save changes -> save the edit box to the file. Commit file to > repository. > if conflict -> React to conflict. > Add a seperate box in the edit action for an optional edit-comment, > allowing better track and motivations behind changes.
Not sure I follow all this exactly. BoltWire already has a conflict resolution system in place for simultaneous edits. Try it and see if it does not do what you want. Obviously, it's pretty trivial to create timestamped copy of each edited version of a page within the wiki rather than in the stamps directory, if we desired. But as for displaying all the variants--I have no idea how it should look in the browser. > b) the version control aspect includes a history such that every > change is kept and easily displayed. It is simply robust and well > implemented. How is this different say than the undo action? Which shows a history of all the changes, who made them, when, and/or whatever other info we wanted to include in the search template. If we set up our own svn* hierarchy, we are still just talking about a simple search function/template. I just don't know what it should look like. A screenshot? > I would probably implement something such that only parts of the wiki > are kept under version control, a page with each line treated like a > search function, or similar, giving a list of pages to control in the > repository. Although it might be simpler to create a basic svn > replacement of the edit function first, and then refine it... Sure, or we could probably do something with info vars. Or just custom edit actions if you could but all your svn pages in a svn* hierarchy. Then it's just creating a custom action.svn.edit page. > Looking at the problem from subversions point of view, I would > probably start with a list of all of subversions commands, and look at > where I would implement them in boltwire. svn add->action.create, svn > co-> when editing etc. Are you wanting to export BoltWire pages to an actual SVN directory, or replicate SNV functions within BoltWire. Two different things. BoltWire does have a simple hook for reading and writing pages that could be tapped into to store the whole page in a svn directory, rather than BoltWire's pages directory. > It would be nice to allow users to use the svn repository as well as > the wiki. This would require boltwire to routinely call svn update. > The viability depends on the speed of local svn connections, although > for my wiki that would not be a problem, with my 20 odd users. I don't know enough about svn to respond to this, but again we can customize the read/write functions to call any script we wish. Might be a lot easier than you think. If php can tell svn to read/write a page, BoltWire can do it just as easy. I could show you how if you let me know what kind of code would be involved on the svn side. > so... put pages/ under version control. Files and images would just > result in having 2 copies which is unnecessary. Fix edit function to > employ commiting of changes. Fixing other actions such as rename > (move), copy, create, etc is fairly easy. If svn has a sufficiently > fast interface for update, calling update on each file or the whole > directory before serving it would be a bonus. History command is > almost, with some tweaks, simply a call to svn diff 'pagename' and > displaying the output. Not necessarily. As long as BoltWire can read the info saved in SVN back out, it can still use the same img and file directories, and markups rules just the same. It's just a different page store location. We could do the same thing if we wanted, to store all the pages in a database rather than flat text files. Extremely easy, just haven't had a need to get around to it. > And bam. Fully compatible boltwire - subversion interface... > > Additional functions for installation, setting up subversion > repository, $boltsvn in index.php, and we're done, I think... If we are just talking about the page store, we only need a simple plugin you flip on and off. Or as you suggested, flip on for certain directories. >> To be honest, I've never used subversion, and only know the basics of >> what it is supposed to do. But not how it actually looks to the end >> user. If you could fill in some of the blanks for your specific need >> we might be able to come up with something. > > It's cli based, so it doesnt look like much :p > Any solution that lets multiple users edit the same file at the same > time is acceptable. Subversion is simply the given way to do that. > Anything else would be an attempt to re-code subversion from scratch. I'm more interested in the directory structure and the file formats of pages. Is it database? How are pages stored, retrieved, the various versions compared/selected. That's the kind of nuts and bolts stuff I don't understand. I guess I could install a version of it to look around in. Probably should use it for BoltWire's development. Do you have a source you recommend I look into? Cheers, Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
