Edgewall Software

Opened 19 years ago

Last modified 9 years ago

#1465 new enhancement

Trac could use a distributed VCS storage

Reported by: jens@… Owned by:
Priority: lowest Milestone: next-major-releases
Component: wiki system Version: 0.8.1
Severity: critical Keywords: objectstore
Cc: davidf@…, leho@…, itamarost@… Branch:
Release Notes:
API Changes:
Internal Changes:



a friend and i are running a small publishing house, and are collaborating with trac and instant messaging - kudos to you, because it does just about all we need!

here's what trac doesn't do very well: we both use laptop computers, and are travelling quite often. in order to work on shared documents, we need to be online constantly, as conventiently most of our shared documents are in wiki format by now. it's not always possible to guarantee internet connetcivity, though…

i realise that subversion is not the ideal repository format for our needs, we really need something like monotone that works well with local repositories that can be merged with a central repository or updated from there. still, writing a whole set of tools such as trac offers on top of monotone would be quite tedious.

so, in a roundabout way what i'm asking is whether it would be possible to run trac in a 'local' mode where it reads the subversion repository information from a local copy _only_ (with limited history/changeset functionality, of course). in addition, trac should store all wiki, ticket and other data in a filesystem structure instead of a db that can also be manages via a seperate or the same subversion repository.

a "commit now" or "i'm online, try to merge with the central repository" button or something similar might be all that's left to make trac the ultimate in collaboration tools.

now being a developer myself in my day job, i realize that this could be a HUGE feature. depends on your architecture, and even if it lends itself to implement something like that, HUGE just reduces to LARGE.

still, i'd like to see it :)

Attachments (0)

Change History (17)

comment:1 by anonymous, 19 years ago

Component: wikigeneral

sorry, should be 'general', not 'wiki'

comment:2 by Christian Boos, 19 years ago

The problem is that Trac doesn't use Subversion as a backend for storing the wiki documents. If that would be the case (as advocated in TighterSubversionIntegration), you could work in a distributed mode using SVK:

  • you would have a central SVK repository in your office, as well as a central Trac on the same machine
  • you would have your own SVK repository on your laptop, as well as a local Trac
  • every local change made on the local Trac would be written in the local SVK repository
  • when you want to synchronize, simply synchronize repositories at the SVK level.

I always thought that it was not a good idea to re-create a (simple) versioning system for versioning Trac's content, rather than using SVN. Now I think it would be really a bad idea to re-create a "light" distributed versioning system, given the complexity of such a thing, and the fact that a good alternative exist.

comment:3 by anonymous, 19 years ago

I don't care how it is done, but the ability to sync trac pages and tickets would be of huge benefit to me. I spend half my time working on a laptop anywhere from my back garden, to the top of a mountain. Network connectivity is lacking most of the time and whilst I really like Trac the inability to work 'offline' is a major problem for me.

I need to grab the latest trac info before I leave the network and sync it when I re-connect.

comment:4 by Christopher Lenz, 19 years ago

Component: generalwiki

comment:5 by Christian Boos, 18 years ago

Keywords: objectstore added
Owner: changed from Jonas Borgström to Christian Boos

Using mergeable repositories as the storage backend for Trac would make this possible. See also #1132.

comment:6 by Christian Boos, 17 years ago

Milestone: 2.0

Worthwhile long term goal.

comment:7 by Christian Boos, 17 years ago

Summary: have trac store wiki pages in a filesystemTrac could use a distributed VCS storage

Changing the summary, so that one doesn't mix its purpose with simple caching (like #1216).

comment:8 by davidf@…, 17 years ago

Cc: davidf@… added

comment:9 by Christian Boos, 16 years ago

Of interest:

comment:10 by Christian Boos, 14 years ago

Milestone: 2.0unscheduled

Milestone 2.0 deleted

comment:11 by anatoly techtonik <techtonik@…>, 14 years ago

I may propose the following plan:

  1. merge tracd and trac-admin into single trac utility
  2. trac init creates default environment in .trac subdir in current directory
  3. if there is are version control folders like .hg or .svn in current directory - they are automatically imported into trac browser
  4. trac serve launches trac on port 8080

In future:

  1. trac sync <URL> - syncronize with remote trac - it may be web-based or command line operation

See how can we use operational transformation protocol http://www.waveprotocol.org/whitepapers/operational-transform

comment:12 by Christian Boos, 14 years ago

Milestone: triagingnext-major-0.1X
Priority: normallowest
Severity: normalcritical

This is definitely something which would be great to achieve in the long run.

comment:13 by lkraav <leho@…>, 14 years ago

Cc: leho@… added

comment:14 by Itamar Ostricher, 14 years ago

Cc: itamarost@… added

comment:15 by lkraav <leho@…>, 13 years ago

something related i discovered today: https://github.com/andychilton/cil

comment:16 by hello@…, 12 years ago

Consider https://github.com/ivanchoo/TracWikiSync for wiki synchronization only.

comment:17 by Ryan J Ollos, 9 years ago

Owner: Christian Boos removed

Modify Ticket

Change Properties
Set your email in Preferences
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.