Defect #2509
closed
autofetch with cvs repository does not find changes in sub folders
0%
Description
Did some testing as to why redmine will pick up some changes in cvs and not others.
I noticed that it will pick up all changes in the root folder of the cvs repository, but if there are changes in sub folders it will not pick them up and assign to a revision id. (You can still browse to the file and see the changes there).
Files
Updated by Jean-Philippe Lang almost 16 years ago
- Assignee deleted (
Jean-Philippe Lang) - Estimated time deleted (
4.00 h)
Updated by Jean-Philippe Lang almost 16 years ago
I can't reproduce this problem. Changes that occur in subfolders are loaded for me.
What is your CVS version and OS?
Updated by Will Vanderpol almost 16 years ago
I just had a thought, since this used to work perfectly on another server in 0.7.3.
On the new server I have Redmine 0.8.0 running on mysql, I have the following options set in my.cnf
auto_increment_increment=2
auto_increment_offset=2
This causes all issues to have even numbered id's, and other problems too. I bet this is causing the repository issue as well. I can't test this right now, unfortunately, the database needs this turned on for replication reasons.
Updated by Will Vanderpol almost 16 years ago
Updated by Will Vanderpol almost 16 years ago
- File changesets_ordered.txt changesets_ordered.txt added
- File changesets_unordered.txt changesets_unordered.txt added
I have removed the mysql autoincrement settings listed above, however the bug still occurs.
Looking in the changesets table I noticed that revision is a varchar(255) field rather than numeric?
It also looks like you assume the the id is ordered with revision, but the attached text file will show otherwise.
As the id increments in the changesets_ordered.txt file, the revision seems to be in a random order?
When I select without the order clause (changesets_unordered.txt), the revision field is sorted, alphanumerically, not numerically.
I have a feeling the initial population of changesets has a sorting issue, which is not apparent if you start a new repository.
Updated by Will Vanderpol almost 16 years ago
Bill Vanderpol wrote:
I have a feeling the initial population of changesets has a sorting issue, which is not apparent if you start a new repository.
Should read:
I have a feeling the initial population of changesets has a sorting issue, which is not apparent UNLESS you start a new repository.
Updated by Will Vanderpol over 15 years ago
- Status changed from New to Resolved
Well, I made the switch to svn, and it doesn't have this problem. My problem is gone.
Updated by Jean-Philippe Lang almost 15 years ago
- Status changed from Resolved to Closed