Defect #2509
closed
autofetch with cvs repository does not find changes in sub folders
Added by Will Vanderpol over 15 years ago.
Updated about 14 years ago.
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
- Assignee deleted (
Jean-Philippe Lang)
- Estimated time deleted (
4.00 h)
I can't reproduce this problem. Changes that occur in subfolders are loaded for me.
What is your CVS version and OS?
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.
Running Gentoo Linux, CVS version is 1.12.12-r4, rails 2.1.2, ruby 1.8.6_p187-r1
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.
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.
- Status changed from New to Resolved
Well, I made the switch to svn, and it doesn't have this problem. My problem is gone.
- Status changed from Resolved to Closed
Also available in: Atom
PDF
Updated by 
Updated by