You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jay Levitt <li...@shopwatch.org> on 2005/10/18 21:49:16 UTC
VOLUNTEER: Port dev docs to a wiki
I'm starting to dive into subversion development so I can fix a few
long-standing VirtualHost/mod_dav_svn bugs that I keep hitting, and I'm
noticing that most of the major documents are several years old, and
obviously pre-1.0.
In theory, everyone could contribute today to these docs; they're in
SVN, and we could submit patches. In reality, the effort of going
through a patch submission just to clarify some language or add a
helpful tip is a barrier. (My existence proof is, again, the state of
the docs.) Meanwhile, there's talk about how to automate processes so
the project can handle more developers. Well, have -I- got a solution
for -you-.
From my brief experience with developer wikis in the Rails world, wikis
are better at staying current. Technically, they're no different than
checked-in text files as we have today. But you're read them online,
and if you see something that needs changing, you click a button and
change it, right then and there. They tend to need "gardening" once in
a while, to refactor a bunch of comments into a more coherent form, but
they remain updated due to their more interactive nature; every reader's
an editor. And, of course, they're revision-controlled. There have been
problems with wiki spam, but that's easily solvable with minimal access
controls/registration.
I'd be willing to do the work to port the existing docs to a wiki and
set it up; I'm thinking Trac, since that could pave the way for eventual
migration from bugzilla to Trac for issue-tracking, if such a thing is
ever desired. (In fact, I'd be willing to do the work for that, too;
the tight integration between design docs, issue tracking and source
code is a wonder to behold.)
Is this desired by the dev team? I could pre-host it on my own server
for testing, and then just tar the whole thing up to transfer to tigris
when people feel it's ready for prime time.
Jay Levitt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Max Bowsher <ma...@ukf.net>.
Daniel Rall wrote:
> On Thu, 20 Oct 2005, Max Bowsher wrote:
> ...
>> The one point on which I hesitate is the lack of review of changes
>> implied by the wiki method.
>>
>> If a wiki was to be used, I think it would need to support the
>> review of changes by a group of appropriately authorized users. To
>> not stray to far away from the wiki concept, I'd OK with unreviewed
>> changes still being displayed, just so long as, long-term, there is
>> a way to ensure at least one committer has confirmed the correctness
>> of changes.
>
> Like most software, Wikis can usually be made to send email.
> (Moin-Moin has been configured to do this for the ASF.) Review could
> occur through via mails to the commits@ list, along the lines of what
> happens for code reviews.
I dislike this option, because it is very much like our current mailing list
moderation interface, and shares the problem of lacking any way of
indicating 'someone else has already reviewed this change'.
I would prefer there to be some sort of centralized viewable list of
unreviewed changes.
> p.s. I'm not trying to endorse use of a Wiki.
Me neither - I still think patches work, given occasional reminders.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Thu, 20 Oct 2005, Max Bowsher wrote:
...
> The one point on which I hesitate is the lack of review of changes implied
> by the wiki method.
>
> If a wiki was to be used, I think it would need to support the review of
> changes by a group of appropriately authorized users. To not stray to far
> away from the wiki concept, I'd OK with unreviewed changes still being
> displayed, just so long as, long-term, there is a way to ensure at least
> one committer has confirmed the correctness of changes.
Like most software, Wikis can usually be made to send email. (Moin-Moin has
been configured to do this for the ASF.) Review could occur through via
mails to the commits@ list, along the lines of what happens for code reviews.
- Dan
p.s. I'm not trying to endorse use of a Wiki.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Daniel Berlin <db...@dberlin.org>.
On Fri, 2005-10-21 at 02:56 +0200, Branko Čibej wrote:
> Justin Erenkrantz wrote:
>
> > --On October 20, 2005 8:32:08 PM +0200 Branko Čibej <br...@xbc.nu> wrote:
> >
> >> If the wiki can be made to commit changes to our repository, then I'll
> >> support CTR for the docs, because we'll get the usual commit e-mails for
> >> review.
> >
> > CTR for everyone or just the committers? -- justin
>
> Ah, good question. Only for committers, but maybe we should lower the
> bar for getting docs commit access. Anyone who's willing to take the
> time to improve our documentation gets my +1.
>
>
Maybe this is the time where i chime in and say i've been fighting for a
while to try to get gcc to put a lot more of it's docs in wiki form, and
just generate xhtml/pdf versions from those.
Be glad you guys don't have to deal with texinfo.
I also set up gcc's wiki, and can tell you if you want something you can
maintain the *code* for, don't use phpwiki.
We're moving to moin-moin.
It even supports writing pages in docbook, and having them display
nicely as html.
(It has a couple "formatters", which allow you to write wiki page in
things other than the moin-moin normal wiki syntax. I wrote one for
texinfo that works nicely).
I'm +1 on having a wiki.
The only thing i can say is be careful what software you choose. Not
necessarily for syntax, but for being able to maintain it. Some of the
more well known wikis apparently have very bad codebases from a
maintainability standpoint.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
> --On October 20, 2005 8:32:08 PM +0200 Branko Čibej <br...@xbc.nu> wrote:
>
>> If the wiki can be made to commit changes to our repository, then I'll
>> support CTR for the docs, because we'll get the usual commit e-mails for
>> review.
>
> CTR for everyone or just the committers? -- justin
Ah, good question. Only for committers, but maybe we should lower the
bar for getting docs commit access. Anyone who's willing to take the
time to improve our documentation gets my +1.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On October 20, 2005 8:32:08 PM +0200 Branko Čibej <br...@xbc.nu> wrote:
> If the wiki can be made to commit changes to our repository, then I'll
> support CTR for the docs, because we'll get the usual commit e-mails for
> review.
CTR for everyone or just the committers? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Branko Čibej <br...@xbc.nu>.
Max Bowsher wrote:
> The one point on which I hesitate is the lack of review of changes
> implied by the wiki method.
If the wiki can be made to commit changes to our repository, then I'll
support CTR for the docs, because we'll get the usual commit e-mails for
review.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Julian Foad <ju...@btopenworld.com>.
Jay Levitt wrote:
> Max Bowsher wrote:
>
>> I'm sorry, but I personally do not support the idea of putting either
>> svn-design or webdav-usage in a Wiki. Both are quite technical
>> documents - assuming that newbies will be able to usefully contribute
>> to them seems unrealistic to me. The people who can work on these
>> documents are the kind that have made significant study of the code -
>> this kind of person should not find sending a patch any sort of
>> barrier. Add to that, that these documents are ones where peer review
>> of changes is especially valuable, to ensure that misunderstandings do
>> not propagate into the documentation. Therefore, I do not think a Wiki
>> is a useful tool in this case.
I infer that Max has not used a Wiki for technical documentation. Nor have I
used one (for any purpose), and I can see his point of view. I have also seen
one that was intended to be but was obliterated by spam. But ...
> I can see why you would think that, but I must respectfully disagree -
> I've seen it work. (http://wiki.rubyonrails.com is a great example.)
> No, a brand-new svn developer is not going to be able to rewrite the
> whole doc. But they'll be able to point out things that seem unclear,
> and make suggested changes, comments, ask inline questions, etc.
[...]
... you, Jay, make a very convincing case, and I am inclined to believe you.
The best thing to would be to set it up, encourage people to use it a bit, and
see what happens. We can't possibly lose anything since we are into version
control. The only thing that can go wrong is that errors start to be
propagated, and so we need to keep a close eye on it for a while and make sure
we prevent that by one means or another. In the worst case we simply shut it
down; in the best case we evolve some sort of auditable review process.
Please do show us.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Brian Behlendorf <br...@collab.net>.
I like Wikis. That said:
On Thu, 20 Oct 2005, Jay Levitt wrote:
> So wiki changes end up creating a very different model of documentation; they
> take advantage of the fact that we can use the same language for both the
> document itself and the conversation about the document. I think a commit
> e-mail for every wiki commit would create ridiculous volumes, and be
> counterproductive. I also think wiki editing should very explicitly *NOT* be
> restricted to commiters alone; again, your most valuable feedback is going to
> come from someone who's reading this thing for the first time, and has yet to
> write a single line of code.
>
> I do think it makes a lot of sense to have the wiki "funnel into" the static
> docs, with a proper review process. Perhaps I could integrate something into
> a wiki engine that flags any given version of the page as "reviewed"; if the
> last editor was not on the commit list, it could say "This page has not yet
> been formally reviewed. Click *here* for the last approved revision.". In
> fact, that seems like useful wiki functionality in general. Would that
> address concerns of documentation gone wild?
Isn't it easier to review commits, not whole pages? That's why some want
the commit emails, and those are kept on another list anyways so anyone
who doesn't want to see them doesn't have to. It's also important to
review each change separately, rather than to say "OK, TrustedCommitterBob
made the last change on this page, therefore all the other un-reviewed
changes must be OK", which it sounds like is your suggested approach.
Bob might be in a hurry just to fix one thing he saw on a page, and didn't
have time right then to review everything else.
I think making it easy to submit fixes makes sense - perhaps there's some
way where the edit-this-page link triggers a patch submission to the dev
list. To address the concern that unreviewed content might appear
authoritative, perhaps we keep the patched page around as a "suggested
improvement" linked off the unchanged page in question, with an easy way
to access all "suggested improvements" by people with authority to promote
that improvement to a core fix.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Jay Levitt <li...@shopwatch.org>.
Max Bowsher wrote:
> [Note: The message to which I am replying does not seem to have
> reached the dev@ list at all. I got it by private copy only, and I
> can't see it in the svn.haxx.se archives either]
Apologies to all... it seems my rewrite-the-from-line procmail recipe
suddenly stopped liking combined list and non-list recipients, and so
-none- of my posts were reaching the list except through quoted
replies. I think I've worked around that.
>
> Jay Levitt wrote:
>
> I'm sorry, but I personally do not support the idea of putting either
> svn-design or webdav-usage in a Wiki. Both are quite technical
> documents - assuming that newbies will be able to usefully contribute
> to them seems unrealistic to me. The people who can work on these
> documents are the kind that have made significant study of the code -
> this kind of person should not find sending a patch any sort of
> barrier. Add to that, that these documents are ones where peer review
> of changes is especially valuable, to ensure that misunderstandings do
> not propagate into the documentation. Therefore, I do not think a Wiki
> is a useful tool in this case.
I can see why you would think that, but I must respectfully disagree -
I've seen it work. (http://wiki.rubyonrails.com is a great example.)
No, a brand-new svn developer is not going to be able to rewrite the
whole doc. But they'll be able to point out things that seem unclear,
and make suggested changes, comments, ask inline questions, etc. It's a
much more organic process than the edit-patch-commit process; you
shouldn't try to think of a wiki as just a webby way to edit and commit
doc patches.
Newcomers often make the best reviewers for tech docs, because they'll
ask the basic questions that you realize need to be addressed by the
doc. If I notice something on a wiki that seems wrong or incomplete,
I'll just add a quick note, or a suggested change, or caveats. Other,
more knowledgeable readers will pick up on that, expand and correct my
correction. Eventually someone refactors the section so that the
conversation disappears, and the end result is a corrected section.
It's a living, breathing, collaborative document, with the conversations
and FAQs and reference all integrated.
But with static files, none of that happens. Yes, I could post to the
list to ask if a line in the documentation is still correct, but due to
the high volume here, that's (understandably) discouraged. I'd be
remiss in posting "Hey, I tried the example in the documentation, but
got this error" to the dev list until I did a whole bunch of research
and debugging on my own. By the time I find out the answer ("This
doesn't work when SVNParentPath is used"), I'm ten steps removed from
the docs. I'm not likely to go back and commit a patch to the docs,
especially if the "problem" was my own misunderstanding - yet that's
exactly the type of situation that can help improve documentation.
Yes; occasionally, someone will post something that sounds definitive,
and yet is entirely wrong. But the exact same thing happens in
peer-reviewed, static docs like we have now, because things that were
true when the doc was written are no longer true, or because the writer
(an expert) made certain assumptions that the reader did not. My
contention, and experience, is that the wiki will, on average, be MORE
correct than the static docs.
So wiki changes end up creating a very different model of documentation;
they take advantage of the fact that we can use the same language for
both the document itself and the conversation about the document. I
think a commit e-mail for every wiki commit would create ridiculous
volumes, and be counterproductive. I also think wiki editing should
very explicitly *NOT* be restricted to commiters alone; again, your most
valuable feedback is going to come from someone who's reading this thing
for the first time, and has yet to write a single line of code.
I do think it makes a lot of sense to have the wiki "funnel into" the
static docs, with a proper review process. Perhaps I could integrate
something into a wiki engine that flags any given version of the page as
"reviewed"; if the last editor was not on the commit list, it could say
"This page has not yet been formally reviewed. Click *here* for the
last approved revision.". In fact, that seems like useful wiki
functionality in general. Would that address concerns of documentation
gone wild?
Jay
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Max Bowsher <ma...@ukf.net>.
[Note: The message to which I am replying does not seem to have reached the
dev@ list at all. I got it by private copy only, and I can't see it in the
svn.haxx.se archives either]
Jay Levitt wrote:
> Max Bowsher wrote:
>
>> Jay Levitt wrote:
>>
>>> I'm noticing that most of the major documents are several years old,
>>> and obviously pre-1.0.
>>
>>
>> Which docs are you speaking of?
>>
>> The "svn-design" texinfo document has always been an unchanging
>> snapshot of the project's early design goals.
>> If you are proposing to update, that, then that document alone would
>> be a significant project in it's own right.
>
> I'm proposing that by putting it in a wiki, it would in fact get
> updated over time as newbies come on board, read it, spot one or two
> things each that aren't accurate anymore, and fix it. I agree that
> trying to update it as a formal project would be a huge bit of work,
> and probably not an itch that anyone has (like most of the
> documentation). That's what's great about wikis - bite-sized
> refactoring, updating and correcting of documentation, instead of
> only wholesale, highly-motivated rewrites.
>>
>> You mention documents, plural, though - what others were you
>> thinking of?
>
> I was reading the webdav-usage doc to try and understand the protocol
> dumps I'm looking at, but most of the meat is "further info to come".
> I also looked at many of the files in /notes.
I'm sorry, but I personally do not support the idea of putting either
svn-design or webdav-usage in a Wiki. Both are quite technical documents -
assuming that newbies will be able to usefully contribute to them seems
unrealistic to me. The people who can work on these documents are the kind
that have made significant study of the code - this kind of person should
not find sending a patch any sort of barrier. Add to that, that these
documents are ones where peer review of changes is especially valuable, to
ensure that misunderstandings do not propagate into the documentation.
Therefore, I do not think a Wiki is a useful tool in this case.
There is also the point that the target audience of these documents is
people who will write and contribute code - i.e. people who will be sending
patches anyway.
The same arguments apply to notes/.
>> To not stray to far away from the wiki concept, I'd OK with
>> unreviewed changes still being displayed, just so long as, long-term,
>> there is a way to ensure at least one committer has confirmed the
>> correctness of changes.
>
> So how are decisions on policy issues like this made? Rough consensus
> on the list? Should I sum up the revised proposal and ask for approval
> votes? Something else?
Consensus on dev@, voting only if consensus fails to be achieved.
So, we continue this discussion, and see what comes of it.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Max Bowsher <ma...@ukf.net>.
Jay Levitt wrote:
> I'm noticing that most of the major documents are several years old,
> and obviously pre-1.0.
Which docs are you speaking of?
The "svn-design" texinfo document has always been an unchanging snapshot of
the project's early design goals.
If you are proposing to update, that, then that document alone would be a
significant project in it's own right.
You mention documents, plural, though - what others were you thinking of?
> In theory, everyone could contribute today to these docs; they're in
> SVN, and we could submit patches. In reality, the effort of going
> through a patch submission just to clarify some language or add a
> helpful tip is a barrier. (My existence proof is, again, the state of
> the docs.) Meanwhile, there's talk about how to automate processes so
> the project can handle more developers. Well, have -I- got a solution
> for -you-.
>
> From my brief experience with developer wikis in the Rails world,
> wikis are better at staying current. Technically, they're no
> different than checked-in text files as we have today. But you're
> read them online, and if you see something that needs changing, you
> click a button and change it, right then and there. They tend to
> need "gardening" once in a while, to refactor a bunch of comments
> into a more coherent form, but they remain updated due to their more
> interactive nature; every reader's an editor. And, of course, they're
> revision-controlled. There have been problems with wiki spam, but
> that's easily solvable with minimal access controls/registration.
The one point on which I hesitate is the lack of review of changes implied
by the wiki method.
If a wiki was to be used, I think it would need to support the review of
changes by a group of appropriately authorized users. To not stray to far
away from the wiki concept, I'd OK with unreviewed changes still being
displayed, just so long as, long-term, there is a way to ensure at least one
committer has confirmed the correctness of changes.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Christian Stork <cs...@ics.uci.edu>.
[Lots of complications using a wiki right now for the official svn
documentation...]
How about setting up a wiki seeded with the current docs, linking to it
from the official site, and periodically (maybe on a weekly basis)
checking in useful changes from the wiki to the repository via the
regular submission procedures?
Such a wiki could be maintained by a volunteer rather independent of the
offical project.
Just an idea.
--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard <ma...@softlanding.com> writes:
> Given the popularity and usefulness of Wiki's for collaboration doesn't it
> stand to reason that CollabNet will likely add a Wiki to CEE in some
> future version?
It certainly does stand to reason.
> If it is on their roadmap couldn't we just wait until it makes it's
> way to tigris.org?
>
> Of course the hard part here is getting CollabNet to provide their plans
> in this area. It seems like there are a lot of projects at tigris.org
> that could benefit from a Wiki.
Yep, CollabNet isn't exposing its roadmap. So if/when wikis make an
appearance in the CollabNet product is unknown. Also unknown is when
tigris.org would get upgraded to a new wifi-ful version of CollabNet,
and if wiki functionality would be enabled on that site. Also unknown
is whether any such wiki offering would by Subversion-backed (as
others here have expressed a desire to have).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Mark Phippard <ma...@softlanding.com>.
cmpilato@localhost.localdomain wrote on 10/19/2005 11:41:26 AM:
> JP Fiset <jp...@fiset.ca> writes:
>
> > Martin Tomes wrote:
> >
> > > These two use Subversion for storage but don't look to be that easy
> > > to set up:
> > >
> > > http://www.jspwiki.org/
> >
> > I use JSP Wiki and like it. You need a servlet container (like Tomcat)
> > to host it. Is a servlet container available to projects on Tigris?
>
> Tigris runs Tomcat, IIRC. But we can't go installing Wikis
> willy-nilly there -- that's a CollabNet-owned-and-operated box. We
> (meaning, those of us CollabNet employees with admin access to it)
> could setup something on svn.collab.net though. It's not currently
> running a servlet container of any sort, but I doubt such would be
> terribly hard to setup.
Given the popularity and usefulness of Wiki's for collaboration doesn't it
stand to reason that CollabNet will likely add a Wiki to CEE in some
future version? If it is on their roadmap couldn't we just wait until it
makes it's way to tigris.org?
Of course the hard part here is getting CollabNet to provide their plans
in this area. It seems like there are a lot of projects at tigris.org
that could benefit from a Wiki.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by "C. Michael Pilato" <cm...@collab.net>.
JP Fiset <jp...@fiset.ca> writes:
> Martin Tomes wrote:
>
> > These two use Subversion for storage but don't look to be that easy
> > to set up:
> >
> > http://www.jspwiki.org/
>
> I use JSP Wiki and like it. You need a servlet container (like Tomcat)
> to host it. Is a servlet container available to projects on Tigris?
Tigris runs Tomcat, IIRC. But we can't go installing Wikis
willy-nilly there -- that's a CollabNet-owned-and-operated box. We
(meaning, those of us CollabNet employees with admin access to it)
could setup something on svn.collab.net though. It's not currently
running a servlet container of any sort, but I doubt such would be
terribly hard to setup.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by JP Fiset <jp...@fiset.ca>.
Martin Tomes wrote:
> These two use Subversion for storage but don't look to be that easy to
> set up:
>
> http://www.jspwiki.org/
I use JSP Wiki and like it. You need a servlet container (like Tomcat)
to host it. Is a servlet container available to projects on Tigris?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Martin Tomes <li...@tomes.org>.
Marcus Rueckert wrote:
> On 2005-10-19 13:22:20 +0200, Branko Čibej wrote:
>
>>We'd still want the wiki page sources stored in Subversion. So Trac is a
>>non-starter, and AFAIK subwiki is the only wiki implementation that
>>stores pages in SVN.
I had to give up with SubWiki because it was too easy to SPAM it and I
got fed up with removing links to porn sites.
These two use Subversion for storage but don't look to be that easy to
set up:
http://www.jspwiki.org/
http://cgi.afc.no-ip.info/svnwiki.cgi/default/svnwiki
--
Martin Tomes
echo 'martin at tomes x org x uk'\
| sed -e 's/ x /\./g' -e 's/ at /@/'
Visit http://www.subversionary.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Branko Čibej <br...@xbc.nu>.
Marcus Rueckert wrote:
>On 2005-10-19 13:22:20 +0200, Branko Čibej wrote:
>
>
>>We'd still want the wiki page sources stored in Subversion. So Trac is a
>>non-starter, and AFAIK subwiki is the only wiki implementation that
>>stores pages in SVN.
>>
>>
>
>thats not true. i know that at least kwiki supports svn storage too.
>others most likely too.
>
>
You're right, I looked at kwiki and it looks like it could be made to
work qiote nicely.
>and i think it should be rather easy to teach trac svn storage too.
>
>
Now _that_ is something I'd like to see. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Marcus Rueckert <da...@web.de>.
On 2005-10-19 13:22:20 +0200, Branko Čibej wrote:
> We'd still want the wiki page sources stored in Subversion. So Trac is a
> non-starter, and AFAIK subwiki is the only wiki implementation that
> stores pages in SVN.
thats not true. i know that at least kwiki supports svn storage too.
others most likely too.
and i think it should be rather easy to teach trac svn storage too.
darix
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Branko Čibej <br...@xbc.nu>.
Jay Levitt wrote:
> Branko Čibej wrote:
>
>> Jay Levitt wrote:
>>
>> We'd still want the wiki page sources stored in Subversion. So Trac
>> is a non-starter, and AFAIK subwiki is the only wiki implementation
>> that stores pages in SVN.
>
> Ah, ok. Is that for dogfood reasons (svn docs should be in svn, ipso
> facto), or for workflow (when you check out SVN, you get the docs, and
> when you check it in, you can update it)?
Workflow reasons, of course. We want to keep a history of the docs
changes in our repository.
> What state is subwiki in? I got the impression from Greg's last post
> on the topic that it's technically active but hasn't gone anywhere.
> Subwiki's own wiki is apparently down or dead.
I guess it's in a very... pre-alpha stage. Trying kwiki might be a good
idea.
> If it's more about workflow than dogfood, I suspect the easiest
> solution would be some type of cross-merge - edit the wiki and it
> checks it into svn, and vice-versa.
>
>> since that could pave the way for eventual migration from bugzilla to
>> Trac for issue-tracking, if such a thing is ever desired. (In fact,
>> I'd be willing to do the work for that, too; the tight integration
>> between design docs, issue tracking and source code is a wonder to
>> behold.)
>>
>> As long as Subversion is hosted on tigris.org, we'll use whatever
>> issue tracking tigris provides.
>
> No problem; I didn't realize that subversion was limited in its choice
> of tools.
It's not exactly limited, but I think we'd need a lot of incentive to
change the issue tracker.
> I had read that "the issue tracker is becoming a victim of
> Subversion's success", and seen all the (apparently) manual work done
> here for voting, nominating, approving, etc., and thought that Trac
> might be a better workflow fit in the medium- to long-term. If
> bugzilla it is, then bugzilla it shall be; that certainly makes Trac
> less desirable as a pure wiki engine.
>
> darix wrote:
>
>and i think it should be rather easy to teach trac svn storage too.
>
>
>
> I know they've talked about it on the trac lists, but not sure if
> that's easy or hard. I imagine teaching it to "cross-file" with svn
> would be easy, due to its plugin architecture, and teaching it to rely
> on svn as its sole repository would be harder (and certainly beyond my
> abilities right now as a Python novice).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VOLUNTEER: Port dev docs to a wiki
Posted by Branko Čibej <br...@xbc.nu>.
Jay Levitt wrote:
> I'm starting to dive into subversion development so I can fix a few
> long-standing VirtualHost/mod_dav_svn bugs that I keep hitting, and
> I'm noticing that most of the major documents are several years old,
> and obviously pre-1.0.
> In theory, everyone could contribute today to these docs; they're in
> SVN, and we could submit patches. In reality, the effort of going
> through a patch submission just to clarify some language or add a
> helpful tip is a barrier. (My existence proof is, again, the state of
> the docs.) Meanwhile, there's talk about how to automate processes so
> the project can handle more developers. Well, have -I- got a solution
> for -you-.
>
> From my brief experience with developer wikis in the Rails world,
> wikis are better at staying current. Technically, they're no
> different than checked-in text files as we have today. But you're
> read them online, and if you see something that needs changing, you
> click a button and change it, right then and there. They tend to need
> "gardening" once in a while, to refactor a bunch of comments into a
> more coherent form, but they remain updated due to their more
> interactive nature; every reader's an editor. And, of course, they're
> revision-controlled. There have been problems with wiki spam, but
> that's easily solvable with minimal access controls/registration.
>
> I'd be willing to do the work to port the existing docs to a wiki and
> set it up; I'm thinking Trac,
We'd still want the wiki page sources stored in Subversion. So Trac is a
non-starter, and AFAIK subwiki is the only wiki implementation that
stores pages in SVN.
> since that could pave the way for eventual migration from bugzilla to
> Trac for issue-tracking, if such a thing is ever desired. (In fact,
> I'd be willing to do the work for that, too; the tight integration
> between design docs, issue tracking and source code is a wonder to
> behold.)
As long as Subversion is hosted on tigris.org, we'll use whatever issue
tracking tigris provides.
> Is this desired by the dev team? I could pre-host it on my own server
> for testing, and then just tar the whole thing up to transfer to
> tigris when people feel it's ready for prime time.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org