Changes between Version 16 and Version 17 of MultipleRepositorySupport

Timestamp:

Feb 2, 2009, 2:45:58 PM (15 years ago)

Author:

Christian Boos

Comment:

various updates to reflect the current state of affairs

MultipleRepositorySupport

@@ -12 +12 @@
  - r6465: initial "release" of the branch, ''worksforme''
  - r6469: a few bug fixes
- - r7590: current version is quite good ;-)
+ - r7590: that version was quite good
+ - r7815: current version is still quite good ;-)
 
 The approach is quite simple: beyond repository connectors, there's now repository providers (IRepositoryProvider components) which are responsible for make available a list of named repositories. That name can be arbitrary (in particular, it may contain '/' to denote a pseudo-hierarchy) and will be used as a prefix for any repository path.
@@ -87 +88 @@
 }}}
    - !SvnParentDirRepositoryProvider, for listing all the Subversion repositories present in a given folder
- - currently, a "default" repository (the one defined in the `[trac]` section) ''needs'' to be defined, otherwise the versioncontrol modules are disabled
+ - currently, a "default" repository (the one defined in the `[trac]` section) ''needs'' to be defined, otherwise the versioncontrol modules are disabled [[span(class=important,FIXME)]]
  - ~~fix AJAX query in annotate~~
- - IRepositoryProvider must have a way to signal new content, in order to rebuild the repository name cache
+ - IRepositoryProvider must have a way to signal new content, in order to rebuild the repository name cache - `trac-admin ... repository changeset`, see #7723.
  - support the `.url` repository metadata (#1781)
- - small issue: visual glitch in Firefox 2 for the new Rev column, 
+ - ~~ small issue: visual glitch in Firefox 2 for the new Rev column, 
    where the changeset icon doesn't align properly to the right 
-   (but works fine for every other web browser, including Firefox 3)
+   (but works fine for every other web browser, including Firefox 3) ~~ FF 2 is now dead, isn't it?
  - "normal" feature: it's currently not possible to compare across repositories 
    (the situation is detected, but raises a "not implemented" error). 
    It would be quite useful to be able to do so, and it's doable without much work 
    (only need to compare folders in a backend neutral way, we already do our own diff at the file level)
- - extend to '''cached repositories''', see MultipleRepositorySupport/Cache. [[br]]
+ - extend to '''cached repositories''', see MultipleRepositorySupport/Cache and #7723 [[br]]
    In a first step, the existing cache could be adapted to simply handle more than one repository. [[br]]
    Bonus points if that cache is smart enough to handle multiple scoped repositories without data duplication. [[br]]
@@ -110 +111 @@
 > 1. How can I get the name in the ''Repository Index'' to keep the case in the name? It is converted to lower case.
 
-ConfigParser limitation.
+!ConfigParser limitation (#7378).
 
 > 2. Since you use the init tag as the name to show in the ''Repository Index'', it seems I cannot have a period in the name of the repository as shown.
@@ -118 +119 @@
 > 3. I get a ''default'' in the ''Repository Index'', as well as that same repository listed in the previous single repository manner. I think that when the multiple repositories are listed, and one of them is the same as the trac repository_dir, it does not need to be listed twice or three times.
 
-Yes, known issue, currently it's not possible to get rid of the "default" repository, specified in `[trac]` (see [#TODO]). What you suggest is that aliases (even aliases for the `[trac] repository_dir`) shouldn't be listed, I think that's acceptable, but there should be an easy way to learn about the defined aliases, maybe they can be listed at the bottom of the toplevel page.
+Yes, known issue, currently it's not possible to get rid of the "default" repository, specified in `[trac]` (see [#TODO]). 
+ - one possibility would be to not list aliases (even aliases for the `[trac] repository_dir`). I think that's acceptable, but there should be an easy way to learn about the defined aliases, maybe they can be listed at the bottom of the toplevel page.
+ - OTOH, aliases might be defined simply because they are more convenient names than the "real" ones, so in the end, more flexibility is needed. Add a `.browseable` flag, a la Samba?
 
 > Other than that, so far this is going to meet my needs quite nicely. Thanks!