Tags:
create new tag
, view all tags
Note: Refactoring in progress. The reference to PerlDiff doesn't work yet.

The Issues

Actually, RCS should not be dropped altogether, but it should be made pluggable so that different version control software can be used.

Plugging into existing infrastructure

If a site uses a different version control system (such as CVS, PVCS, Aegis, MS SourceSafe, or whatever), it will consider TWiki more favorably if TWiki will just use existing infrastructure instead of requiring an RCS install.

On Unix boxes, this is actually a non-issue: they usually come with a usable RCS preinstalled.

On the Windows side, you'll need the Cygwin toolchain, which is a bit much to swallow for MS-only shops. Cygwin is slow (by necessity: it must emulate a Unix infrastructure on a Windows system, which means a lot of interpretation and translation), and Cygwin requires attention (configuring Cygwin to that it runs smoothly requires knowledge and time).

RCS installation

RCS installation is a fragile process.

RCS requires GNU diff (or equivalent - many Unix diffs aren't good enough, and Windows' file compare utilities definitely don't qualify).

RCS also requires that a diff always be found at the absolute path where diff was during installation.

Further, installing RCS must be done by recompilation, since the absolute path for diff is patched into the source and compiled into the binaries.

A non-issue on Unix systems, but Windows systems are tailored for installing precompiled binaries. Installing RCS on a Windows system means installing an entire compiler/linker toolchain (as of this writing, only Cygwin is viable, since different C compilers vary enough that RCS won't compile without source code patches - and you _cannot* assume that Windows web administrators know enough C to do that).

rcsdiff

RCS uses diff for delta compression.

TWiki uses the same diff to display differences between revisions, but that's not strictly necessary.

Proposals for using a different differencing tool have been moved to PerlDiff.

RCS services

In this section, we consider what features RCS offers and whether they are relevant for TWiki.

Revision history

RCS allows retrieving previous revisions of a file.

TWiki makes heavy use of this.

This would be easy to do without RCS (just store previous revisions as separate files in a subdirectory).

Delta compression

RCS stores previous revisions of a file in delta-compressed form.

This used to be an essential feature when RCS was written, but it's much less of an issue in the age of gigabyte harddisks.

Unfortunately, large files where delta compression would be most effective tend to be binary files that RCS cannot compress.

Conclusion: nice to have but not essential (and limited anyway).

Revision merge

RCS can merge modifications from different people and show where the modifications conflict.

TWiki does not currently use this, but TWiki will move in a direction where this capability becomes essential (see DistributedTWiki).

There is currently no easy replacement for this, but all revisioning tools have a facility for doing it.

Unfortunately, revisioning tools tend to display conflicts in a way that's not very intuitive, and certainly not optimized for WWW display.

Conclusion: This is what keeps RCS in TWiki.

Solutions

There's a strong movement towards making RCS pluggable.

Discussion

I'm not sure that pluggable versioning is worth the effort.

Writing a merge tool isn't that difficult.

First, a diff3 is needed (diff3 takes an original and two independently modified versions, and lists the differences in a single list). The diff algorithm as implemented in the CPAN module Algorithm::Diff works well and should be moderately easy to adapt (the module has excellent documentation and goes to great lengths to explain the diff algorithm employed).

Second, the merge itself is required. This is actually boilerplate programming: take a difference list as produced by diff3, select all differences that don't overlap, and report a conflict for differences that do overlap.

There are massive advantages on this road. For example, it would be easy to present the merge results like this:

Unchanged your insertion unchanged your deletion unchanged other user's insertion unchanged other user's deletion unchanged
Conflict.
Here's your Change:

Unchanged your insertion unchanged your deletion unchanged
Here's user Foo's Change:
unchanged other user's insertion unchanged other user's deletion unchanged
End of Conflict.
unchanged

The format could be made more compact by adding an explanation at the top of the page.

For the actual merge, TWiki could even provide check boxes on each change so that the user can select what text to keep. (If the user selects both, an edit page could pop up where each conflict is marked - useful if the user wants to integrate the two modifications manually).

As an additional bonus, this technique would make page locking unnecessary.

-- JoachimDurchholz - 05 Feb 2002

Discussion

Here's a radical idea; I'd like to see any input, in favor or not.

Basically, I argue that RCS add more to the problem set than to the solution set in the TWiki context:

  • RCS (well, more specifically GNU diff) doesn't handle structured documents very well. For diff, TWiki text files are just character sequences, it cannot exploit the document structure (with meta tags, HTML hierarchy etc.) to give better guesses of what the actual change is.
  • diff will always list an entire line as changed even if just a single word was modified. This may be appropriate for patching source code, but it's inappropriate for text collaboration. (This is already discussed in WordDiff and DiffsHardToRecognize.)
  • The main features of RCS are its multi-branch handling (which isn't used in TWiki) and its delta compression (which trades time for space, which is actually the reverse of what TWiki usually needs - disk space is cheap, server load is paramount).
  • RCS doesn't solve all problems. In particulare, it cannot handle renaming (which is a long-standing problem for all RCS-based software that I know of, including CVS).

Here's what I have been thinking how RCS could be replaced:

  • Don't use RCS for storing previous revisions. Just use a naming convention, such as topic.txt for the current version, topic.txt1 ... topic.txt999 for previous revisions.
    This needs some Perl logic to properly handle long revision histories (the number of digits shouldn't be limited, and missing intermediate revisions should be properly handled), but nothing really difficult.
  • Replace GNU diff with Perl diff (which is in Algorithm::diff). Perl diff can handle structured documents and will do the diff at exactly the granularity that we want (there is a hook for feeding gobs of data to the diff engine; it should even be possible to run a sub-diff on sections of the input texts).

How about having TWiki switch to use a generic version control interface? I'm sure there are perl modules in CPAN which abstract between RCS and CVS at least (and hopefully others). Habe TWiki use the interface for one of these, so the admin can choose between the different version control platforms. I personally would love a full CVS backend for TWiki. -- AdamTheo - 24 Dec 2002

Open questions that spring to my mind:

  • It's unclear how this will affect efficiency. GNU diff is probably faster than Perl diff, but GNU diff requires starting a new Unix process, which is not a cheap operation.
    It is entirely possible that GNU diff load times are longer than the actual comparison, making Perl diff faster in a CGI context (particularly if mod_perl is used).
  • I've got no idea how well Perl diff works.
  • To make real use of Perl diff, Store.pm would need some heavy reworking. Store.pm isn't exactly a shining example of a closed module, some changes will affect higher levels of the TWiki code (TWiki will pass in some options that it knows are for RCS).

-- JoachimDurchholz - 27 Dec 2001

Roadmap

I'll wait for a while to see how this idea is received. (It's a serious change to TWiki after all.)
I'd also like to do some profiling to get the guesswork out of the performance issues. (I dimly remember that somebody did some profiling, but recall no useful results.)

-- JoachimDurchholz - 27 Dec 2001

Profiling

Since I have zero experience with profiling Perl, any ideas on a suitable suite of tests would be highly appreciated.

For example, I'd like to run a few typical check-ins and diffs in a mod_perl environment on a Unix box. The test should probably be just a single test script that mimicks TWiki's behaviour well enough to draw some preliminary conclusions. Problem: I don't know what's "normal TWiki usage", and I don't have any "typical TWiki site" that I could instrument to gather statistics.

Another problem for running the tests is that I don't have a Unix box ready and running with TWiki.

So I'd appreciate volunteers for the following two tasks:

  • If you have a TWiki site running, add some statistics on how often the various RCS calls are done and how much of total processing time they need. I'll write a script that wraps the RCS calls and does the appropriate logging, so all you need to do is to install the script and change $rcsDir in TWiki.cfg to use that script instead of rcs.
    Of course, it would be even better if somebody could provide some statistics directly smile
  • If you have a Unix box with an Apache server with mod_perl running, run the test script and return the results (or post them here).

-- JoachimDurchholz - 27 Dec 2001

I just uploaded the test script. Somebody with a working Unix box please check it out.
It uses an absolute path to access Algorithm::Diff, so you might have to modify it.

Here are a few test results from my machine (Cygwin on NT):

  Administrator@ENCELADUS ~/PerlRcs
  $ ./test.sh 10
  Times   via RCS  via Perl
  System    0.050    0.010
  User      0.000    0.010
  Total     0.050    0.020

  Administrator@ENCELADUS ~/PerlRcs
  $ ./test.sh 100
  Times   via RCS  via Perl
  System    0.330    0.280
  User      0.130    0.100
  Total     0.460    0.380

  Administrator@ENCELADUS ~/PerlRcs
  $ ./test.sh 400
  Times   via RCS  via Perl
  System    1.442    1.151
  User      0.360    0.441
  Total     1.802    1.592

The "via RCS" figures refer to calls to standard GNU diff (which is normally the same as rcsdiff I think).

The "via Perl" figures call a Perl script.

I tested with a typical TWiki topic (revision 1: one page of text; revision 2: like revision 1 but with another page of text appended).
(Actually I just randomly selected an entry from the lates MailNotify and used the HTML of the last two revisions. It's not exactly what an RCS replacement would see, but close enough IMHO.)

Alternatives for RCS

filenameNN.txt is a bit messy and will probably led to excessive directory IO, plus additional logic in the search area to differentiate between filenameNN.txt and filenameNM.txt results returned by grep.

The idea is a good one though. I've been thinking for a while in replacing RCS with a native format, one file instead of NN files.

There are two ways to do it:

  • simple - full versions stored in chunks within topic.txt file
  • complex - use Algorithm::Diff, write a Perl Algorith::Patch to apply a A::Diff object to a list.

In either case after doing the patch code, a good flocking mechanism is really the only major I can see.

Furthermore, it could be made buzz-word complete using a XML based data-protocol. Extending this would lead to interesting path to follow for XML-RPC I'd guess as well.

There are already profiling result with native perl reads vs. system-rcs based reads. Writes are likely more disk IO bound, and dont happen that often anyway.

I personally don't have time to produce the above at the moment, especially since it would involve a major rewrite of various components of TWiki::*.

See also: NativeVersionFormat, LoadTesting, RenderOnceReadMostly, and others.

-- NicholasLee - 28 Dec 2001

XML would be great, but this would be a major change that I'm not prepared to do.

As for the directory stuff - previous revisions could be stored in subdirectories, so a file-based revision store wouldn't take any more space than the current solution (with the ,v files in the same directory as the topics).
I'm not sure that directory size is a real issue on modern operating systems, but it's a good idea to keep the directories small enough anyway, so a human user can make sense of it.

The reference to Algorithm::Patch made me rethink the proposal though. There are a few issues here:

  • Algorithm::Patch requires some real work beyond a simple replace-the-tools operation. I'm not sure whether that's worth the effort.
  • Any form of distributed TWiki (DistributedTWiki, OfflineTWiki) requires merge capabilities (which means we need a diff3 and a merge). Algorithm::Diff provides none of these, so this would require even more work.
    (With a bit of luck, diff3 and merge are straightforward variations of diff and patch.)

-- JoachimDurchholz - 02 Jan 2002

Alternatives for diff

As for the objections to diff processing, unless I'm missing something, it's not necessary to get rid of RCS in order to use a different differencing tool than rcsdiff.

-- EliMantel - 01 Jan 2002

OK, if that's the case - fine.
However, I'm really wondering whether RCS serves any real purpose:

  • We don't (really) need its delta compression.
  • We don't need its branching and merging capabilities.
  • We don't need its version number bookkeeping.
So why keep it around?

-- JoachimDurchholz - 02 Jan 2002

Algorithm::diff and possibly the rendering used in Web CVS solutions look like a good starting point to me. Some thoughts:

  • speed is unlikely to be an issue
  • can filter out some content before applying the diff (not possible with rcsdiff)
  • could give different options for rendering (similar to some Web CVSs)
  • if it looks promising appropriate hooks can be added to Plugin API

-- JohnTalintyre - 03 Jan 2002

The RCS that came with SuSE Linux has a feature to preprocess the files before passing them to diff.

-- HendrikBoom - 05 Jan 2002

How do these options look like? The GNU diff on my machines doesn't have such options.

-- JoachimDurchholz - 09 Jan 2002

I think the most important point is that TWiki doesn't need or use the whole capability of the RCS format. Delta compression is still useful, and extending Algorith::Diff to deal to binary data is probably required.

-- NicholasLee - 04 Jan 2002

Algorithm::Diff is actually better prepared to handle binary format than rcsdiff. There are two issues here:

  • Filtering.
    rcsdiff has options to skip blanks, tabs, and empty lines, and to replace \r\n with \n, but that's about it.
    This is not a really serious problem: it's always possible to preprocess the files before feeding them to diff.
    (WordDiff gives some considerations on this.)
    Algorithm::Diff has hooks for filtering.

It would be easy to write Perl functions that do the filtering on the fly. (Essentially, this would lessen TWiki's dependency on a Unix-style shell - which is one of the things that make installation of TWiki on Windows a bit difficult.)

  • Clustering.
    rcsdiff has hardcoded assumptions on line ends. I'm not aware of any facilities to get around these.
    Algorithm::Diff has hooks for clustering. (Technically, it's the filtering hooks.)

In fact, RCS stores binary data without doing delta compression. (This property carries over to CVS.)

-- JoachimDurchholz - 09 Jan 2002

Some good points. Any time to submit the low-level code for all the above. wink Getting some tight code to do the above is 80% of the work for this topic. Rewritting the parts of TWiki to use a native version format is pretty easy - mostly just crud work.

-- NicholasLee - 09 Jan 2002

Opinions

Don't Discard RCS!

I don't really appreciate the stated objections to RCS. If it's difficult to install on some platforms, then it might be more reasonable to try and get that problem fixed rather than discarding RCS. Although RCS may have some features such as multi-branch handling which aren't needed by TWiki, this doesn't seem to have any real impact on the quality or reliability of RCS.

If changes are to be made in this area, I would think that the right thing to do would not be to preclude the use of RCS but rather to allow for the use of alternate version control software. There are some version control API's defined, but I don't know if any exist for use with Perl. Regardless, abstracting out the version control functionality used in TWiki isn't likely to be all that difficult, and then people can choose to do whatever they want to with version control.

-- EliMantel - 01 Jan 2002

Replies to the various issues.

If [RCS is] difficult to install on some platforms

Actually it's difficult to install on all platforms. Unix people just happen to have it precompiled and preinstalled (usually).

[Proposal to use general versioning API]

Fine - if you propose it, please dig up the API. Frankly, I don't know where to look, nor where to ask.

-- JoachimDurchholz - 02 Jan 2002

Aren't branching and merging useful when a TWiki is distributed among multiple sites with poor communication? (e.g. several laptops)

-- HendrikBoom - 05 Jan 2002

This is what makes me hesitate at this moment. It's probably easier to replace diff as a first step (RCS-generated diffs aren't good) and think about merging later (or even sticking with RCS).
The actual problems aren't with RCS, they are with diff. Unfortunately, RCS doesn't have an option that tells it which diff command to use; the diff command is diagnosed during installation and compiled into the RCS binaries. (Which also means you have to reinstall RCS if you change the diff utility. RCS is a stinker installation-wise.)

-- JoachimDurchholz - 06 Jan 2002]

Having an alternative to RCS would certainly be good. But, this is a non trivial task as TWiki currently stands. I would start with something that will add value as a possible stepping stone to full alternatives to RCS. I suggest the display of differences as initial work can be done without much impact on the TWiki core.

The issue of full RCS replacement has been talked about before. It would be very advantage to stick with the existing RCS format, which isn't that complex. Otherwise upgrades will be a real pain and distribution of TWiki more difficult.

-- JohnTalintyre - 03 Jan 2002

An important point is that stepping away from RCS makes developing SQL backends and clusters much easier.

These are all ideas though, someone still needs to write the code, its unlike I'll have the time at present. Maybe in the middle or the year I'll pick it up again.

-- NicholasLee - 04 Jan 2002

I've got a first version of RcsLite, which is intended to implement just the part of RCS that TWiki requires. My thought is to slowly put this into TWiki and get the following improvements:

  • Ability to use TWiki without RCS, choice will be based on TWiki.cfg settings
  • Make calls to the storage system mechanism neutral - initally support RCS and RcsLite, but allow for others
  • Improve the TWiki diff output

The first step is likely to be using RcsLite and Algorithm::Diff to give different forms of output for comparing revisions (rdiff).

Suggested module structure:

TWiki::Store - calls would still be made into this
TWiki::Data::RcsLite - Perl minimal implementation
TWiki::Data::Rcs     - access to RCS
TWiki::Data          - generic access to data, including revision control, initially only RcsFile would be supported
TWiki::Data::RcsFile - could use either RcsLite or Rcs to provide full facilities, including renaming

Using Perl objects has some overhead, but this is not the area that TWiki does lots of calls in.

-- JohnTalintyre - 31 Jan 2002

Sounds wonderful!

-- RandyKramer - 31 Jan 2002

Agreed! Right now, for every page file fileFooPageNamePageFoo there is a fileFooPageNamePageFoo,v file. Why not just have a fileFooPageNamePageFoo.old directory. In that directory put files such as 00000000000001. Fixed formatting the names is not something I'm wedded to, but would make some things easier. The files could be compressed or diffs, or whatever. I like the idea of having a plug-in like module so that we can roll our own and play with different ideas. Luckily my TWiki playings around have been on Linux boxes with RCS already installed, and it just works. Very nice.

-- DougPhilips - 01 Feb 2002

It take it your are suggesting using a directory to hold old versions, rather than the ,v file. But, why lose the space and maintanance advantages of a history file? Additionally we always try to make upgrade pains for TWiki small. Switching format of histories won't be completely painless. Some users of TWiki with working RCS setups probably won't want to lose the advantages that brings, so that could mean supporting RCS history and directory based histories - a real pain. So to my mind it's better to let people use RCS or a perl version or maybe in the future a different backend. Note that to support a different backend people would need to load in default TWiki histories and convert; they'd also be the more difficult problem of doing upgrades to the content of Webs like TWiki.

-- JohnTalintyre - 01 Feb 2002

It was more of an off the cuff remark than it sounded. wink Actually, if there is a "backend versioning plugin" ability, it would be a shame if only one could be plugged in at a time. Wouldn't it be cool if you could plug-in your "old" versioning back-end, your "new" versioning back end, and use the system itself to convert 'em?

I'm not advocating that RCS must die anytime soon. By keeping the files in a subdirectory, and by keeping them "whole" you should get better user-response time to accessing "old views". In fact, the current view would just be one particular instance of any view possible, n'est-ce pas? But again, I hadn't really thought through all the implications, I was just tossing out ideas for dead simple version control options.

-- DougPhilips - 01 Feb 2002

By use of Perl objects (see RcsLite) I envisioned being able to use to different backends to do a conversation - but that's somewhere off in the future smile

I didn't realise time to view old revision was a problem.

-- JohnTalintyre - 02 Feb 2002

I'm sure it's not a problem for everybody (like me -- I view an old revision rarely enough that a little extra time is not a problem). If speeding up viewing old revisions involves some trade offs, I suggest you post them before making a change -- see whether the majority of users think the tradeoff will be reasonable.

PS: After I save this page, I'll go back and view some old versions. I'll come back today and post again if I find the time to be objectionable.

-- RandyKramer - 02 Feb 2002

I guess I wasn't specific enough (I knew what I meant. wink ). If every version of every page were always available, the one could get a look at the twiki at some instant in time and see the whole thing linked and all. I don't have a good suggestion for the implementation, but that was what I was hinting at when I referred to user response time.

-- DougPhilips - 02 Feb 2002

Doug,

OK, I'm more confused. When I click on an old version on the edit line below (like 1.18), I see the old version complete with links. Or, are you saying that you want the old version's links to point to old versions of the linked pages? (So that the links point to the versions of the linked pages that were current at the time of the earlier revision of this page?)

I haven't found a need for that so far (but I am sometimes somewhat anal with respect to preserving old versions of documents). I guess I'd ask under what circumstances you find this useful, and reiterate again that we consider the tradeoffs involved before heading in such a direction.

PS: I find no delay in calling up recent old versions of documents -- I haven't tried going back like 100 versions -- may try that just for kicks. (I connect via a dial-up modem, any slight delay seems to be masked by other delays inherent to my dial-up connection.)

-- RandyKramer - 03 Feb 2002

My thought was being able to see the entire TWiki web as it was at some time in the past. My idea for keeping the full content of the old pages available in toto would make analyzing the old web and the changes to it much easier, something you wouldn't necessarily have to do from within the TWiki code itself.

-- DougPhilips - 03 Feb 2002

Ok, understood. If we do this I hope we keep it switch selectable -- I can't see this being of enough value to me to justify (extra storage space, more confusion in directories, etc., etc.)

-- RandyKramer - 04 Feb 2002

I not clear from the above that there is any reason to change from the current history based structure. If for analysis you want each revision in a separate file, than a small bit of coding would create a readonly copy. If you use the files raw you'll lose some things TWiki does for you automatically, like upgrade the content to support META information. Either way, the object based interface will (in time) give you a choice in this.

-- JohnTalintyre - 04 Feb 2002

I'm not wedded to any particular history mechanism, though having to have RCS is somewhat annoying. What I'd really like to see is the ability to use more than one history mechanism at once. That'd make it easy to test out new ones and to migrate...

-- DougPhilips - 04 Feb 2002

When you say ability to use more than one history mechanism at once do you mean in the same TWiki instance? How would you know which one to use? Per Web setting ...?

-- JohnTalintyre - 05 Feb 2002

,v files vs. directories: I don't think there's much of an issue here. Directories are (probably) faster, but current-day processors are so fast that the difference is unnoticeable (I'd reckon it is masked by disk access time). ,v files are smaller, but only for text files (RCS doesn't compress binaries - no, RCS and diff now efficiently compress binaries - ColasNahaboo ), and a few megabytes of text don't really matter in the age of gigabyte harddisks.
My conclusion: Do it the way that's easiest.

Single-topic vs. site revisioning: I don't see any essential differences between storage methods here. Surely the link fixing and meta postprocessing happens after the checkout?
BTW this is a bit of a user interface problem. Currently, if the user follows a link from an old revision, TWiki does not know whether the user wants to see the corresponding revision of the new topic, or the current revision of the new topic. One could add a "historic mode" that will nail down all topics to a given date (default should be the modification date of the last topic revision viewed).

Multiple versioning tools: I don't think that multiple tools within the same TWiki are very useful.
If you want to run tests with a different tool, just set up another TWiki, that's easy enough to do (and will hopefully become even easier in the future).
However, it would indeed be useful to be able to plug in a different revisionin tool.

On a tangent, I'd like to see a split between RCS and diff. RCS uses diff to do its delta compression, but this is actually unrelated to the diffs that TWiki should produce.

-- JoachimDurchholz - 05 Feb 2002

Modularizing the storage backend is the right thing to do. Lets make efforts not to compromize the performance. How about reducing the suggested module structure to fewer packages:

TWiki::Store Calls would still be made into this
TWiki::Data Generic access to data, including revision control. Is an "abstract class with an empty implementation"
TWiki::Data::Rcs Access to RCS via system calls. "Implements" TWiki::Data
TWiki::Data::RcsLite Perl minimal implementation of RCS, see RcsLite. "Implements" TWiki::Data

Regarding diff, yes, it would be better to decouple RCS and diff. That means, to get a diff between two versions you first need to check out the versions and then compare those.

-- PeterThoeny - 05 Feb 2002

I didn't want to have two copies of the rename code, hence the idea of RcsFile, although this always felt somewhat cumbersome. I'm not clear that this has any performance impact (here my main worry is processing large binary files) but I'll see how things go as regards keeping the coding simple.

I totally agree about splitting rcs and diff. There is potentially a small performance hit, but it keeps things much cleaner.

-- JohnTalintyre - 05 Feb 2002

RCS isn't efficient for binaries anyway (no delta compression). Actually RCS doesn't provide any advantages for binaries... it can't merge them, it can't delta compress them. Binaries in RCS are just the various files appended together in the ,v file.

-- JoachimDurchholz - 06 Feb 2002

It would be really cool if I could plug in a different store than RCS, like PerForce. Many firms already have some RCS-like system that is well supported and backed up.

-- DougRansom - 26 Dec 2002

Note, that the major problem is not RCS itself, but the way how TWiki (ab?)uses it to store versions. The typical cycle in SCM tools (including RCS!) is:

  1. check-out revision n to working copy
  2. work, i.e. save multiple micro changes
  3. check-in revision n+1

Now, RCS can be forced to overwrite an existent revision with new stuff. If I understand correctly, TWiki uses this to implement a cycle like:

  1. send revision n to browser for edit
  2. on first save, create revision n+1
  3. on subsequent save (while lock exists), overwrite revision n+1

The advantage of this approach seems to be, that TWiki does not need to fight with the extra case of a working copy: for any save, there's always a valid revision in the repository.

The disadvantage is, that this approach is alien to SCM tools. This makes many things harder than they need to be, e.g.:

Therefore, I propose to change the way TWiki handles the revisions to conform with the "normal" SCM cycle; RcsNonStrictLocking should be a good beginning. Then the above wishlist could be implemented much easier.

-- PeterKlausner - 26 Dec 2002

A simpler approach might be to not use diff -- just store the complete version of any wiki page. They are just text after all, and hard drives are a lot bigger than they used to be.

-- DougRansom - 31 Dec 2002

As Peter said above, [m]odularizing the storage backend is the right thing to do. This is the path through which any fundamental change like "Get Rid Of Rcs" must take. It may not be sexy or simple, but it's necessary to do some hard work here to make it happen. This work will benefit many different areas. Hmm, after a bit of searching I don't see a topic focused just on this aspect of design that's current. I'll start one right here. ModularStorageBackend.

-- GrantBow - 04 Jan 2003

TWiki storage already has a high degree of modularisation, you don't have to use RCS you can use RcsLite - although please note that until there are more sucessful implmenations I regard this as beta quality. You can always implement something else behind this Perl interface - there's even a fair bit of test code in CVS that could help. Certain functions need to supported and these came from an RCS starting point so some version control systems may have a problem. It worth still being able to process RCS histories as many TWiki topics are stored that way - RcsLite could always be to read or write to RCS format files.

-- JohnTalintyre - 01 Apr 2003

Topic attachments
I Attachment History Action Size Date Who Comment
Unix shell scriptsh test.sh r1 manage 1.4 K 2002-01-02 - 10:02 UnknownUser Performance test script
Edit | Attach | Watch | Print version | History: r41 < r40 < r39 < r38 < r37 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r41 - 2003-04-01 - JohnTalintyre
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2015 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.