Project

General

Profile

Actions

Defect #2509

closed

autofetch with cvs repository does not find changes in sub folders

Added by Will Vanderpol about 15 years ago. Updated about 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
SCM
Target version:
-
Start date:
2009-01-14
Due date:
% Done:

0%

Estimated time:
Resolution:
Affected version:

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

changesets_ordered.txt (36.9 KB) changesets_ordered.txt Ordered by id Will Vanderpol, 2009-01-21 21:27
changesets_unordered.txt (36.9 KB) changesets_unordered.txt table default order Will Vanderpol, 2009-01-21 21:27
Actions #1

Updated by Jean-Philippe Lang about 15 years ago

  • Assignee deleted (Jean-Philippe Lang)
  • Estimated time deleted (4.00 h)
Actions #2

Updated by Jean-Philippe Lang about 15 years ago

I can't reproduce this problem. Changes that occur in subfolders are loaded for me.
What is your CVS version and OS?

Actions #3

Updated by Will Vanderpol about 15 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.

Actions #4

Updated by Will Vanderpol about 15 years ago

Running Gentoo Linux, CVS version is 1.12.12-r4, rails 2.1.2, ruby 1.8.6_p187-r1

Actions #5

Updated by Will Vanderpol about 15 years ago

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.

Actions #6

Updated by Will Vanderpol about 15 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.

Actions #7

Updated by Will Vanderpol almost 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.

Actions #8

Updated by Jean-Philippe Lang about 14 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF