#1429 closed enhancement (worksforme)
configurable svn paths to ignore during sync
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | timeline | Version: | 0.8.1 |
Severity: | normal | Keywords: | |
Cc: | paul@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
I'd like to be able to set either a regular expression, or simple wildcard matches in trac.ini to filter out svn activity when syncing the repository.
We've been using trac for the last couple months, and the node_change table already has 700k records. Due to the great sqlite team, it performs fine, however re-syncing the repository when viewing the timeline takes a long time after we create tags (which we do frequently as we use cheap svn tags to represent snapshots for testing).
Just the pure time of inserting several thousand rows into node_change is causing the delay every time a tag is made. I know there is a manual sync command, which could be done periodically so that the delay doesn't occur on the website, however theres practically no value for recording a list of all files for tags (or whatever depending on the project).
Attachments (0)
Change History (6)
comment:1 by , 20 years ago
comment:2 by , 20 years ago
Maybe I'm missing something here, but exactly why do you need to do a complete resync after tagging? Or do you mean normal syncing?
comment:3 by , 20 years ago
I'm running 0.8.1, i'll install the trunk sometime over the weekend and try it out.
Was referring to just normal syncing that occurs when you view the timeline tab. Just takes a minute to do the couple thousand inserts into node_change (or so I would assume is the source of the delay).
comment:4 by , 20 years ago
Cc: | added |
---|
(still based on running 0.8.1)
[1109] is in 0.8.1, if its recorded as a copy, what should I see?
I just tagged the trunk, and hit the timeline page, when I view the changeset, it shows every file as an addition however it did not show the content of the files (thank god).
comment:5 by , 20 years ago
comment:6 by , 20 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
I was basing the statement off the repostiory revision number for the 0.8.1 tag directory, which I now see the flaw in.
In any event, I did setup the trunk last night on the same trac-db/svn-repo, and it does fix the speed issue, so ALL is well.
(as a side note thats a great set of changes to the quality of the svn integration)
Since [1109], the tag operation is simply recorded as one copy operation. If the source of the copy is a huge tree, I believe the sync operation could take some time, but certainly far less than it took before.
Since [1413], there's a new
versioncontrol
layer, which is a complete rewrite of the interface with Subversion, but it still supports the copy operation very efficiently.You should test the current version and see how well it behaves in your case.
status set to feedback :)