Changes between Version 1 and Version 2 of DistributedTrac

Timestamp:

Feb 12, 2009, 9:22:16 AM (15 years ago)

Author:

Christian Boos

Comment:

some comments and further pointers

DistributedTrac

@@ -10 +10 @@
 
 == Hurdles of Distributed Trac ==
- * Merging data could get complicated. If the backend is designed well though, it shouldn't be too bad.
+ * Merging data could get complicated. If the backend is designed well though, it shouldn't be too bad. [[br]]
+   '' That's indeed the key usability point for such a system. 
+   You wouldn't even want to attempt a merge of ticket data at the file level.
+   Instead, the ui should present a way to merge changes, a bit similar to what is planned for resolving conflicts during concurrent edits.
+   Have a look at the discussions in #2618, #4001 and #7145.
+   Conflict resolutions could even be done incrementally, saved on the non-default branch. When there are no conflicts anymore, the merge can proceed and the changes added by the branch will be available on the default branch, at which point the "cache" db can be updated (see next point). -- cboos''
  * Searching through files would be slower than a database.
   * The trac server could create a temporary database from the versioned data. An SQLite memory db could work well for this.
    * It would be really slick if it could recognize when the data has changed and just update an existing import instead of redoing the entire set.
  * Trac data commits could clutter the VCS log making it difficult to find the important code changes amongst many revisions of "Page X changed by Y".
+   '' That's probably the most visible reason about why it's not such a good idea to use the same repository for Trac itself. See the more in-depth discussion of this aspect in TighterSubversionIntegration. Nevertheless, as Trac makes progresses added MultipleRepositorySupport, it wouldn't be such a big deal to use a dedicated repository. -- cboos''
+
+
+----
+See also: #1465