Opened 19 years ago
Closed 18 years ago
#3175 closed defect (duplicate)
No changeset xxx in the repository
Reported by: | sven | Owned by: | Christian Boos |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | version control/browser | Version: | 0.9.4 |
Severity: | major | Keywords: | no changeset repository |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
running linux fedora core 5, apache 2.0.54, trac 0.9.4, subversion 1.2.3.-2.1 current subversion revision: 1400 database using for svn: FSFS
Subversion (is / seems to be) working just perfectly fine, When I do a checkout / update, I get the entire tree as I should. Yet when I try to access part of my repository tree with trac using browse source, I get this following error:
No changeset 360 in the repository
If I check the parent directory in TRAC (..), and change the revision I am viewing to 360, I dont get an error, it shows a revision tree, only the specific directory is missing. This is correct, since this directory used to be in a different location until revision 650 or so.
in bash, svn list .. -r360 (same as viewing the parent directory in trac) also does NOT show me the directory, which is correct.
svn list . -r360 in that specific directory returns content, showing me it to actually should exist.
now, is this a subversion error or trac error? Obviously, this directory didnt exist before, it was moved in place there aournd r650.. so if didnt exist in r360, right.. but why r360? svn log doesnt show any commit at all in that area of the tree on r360, and even so, trac will NOT show me the HEAD tree because r360 doesnt exist.. but it so does! In bash, an ls in the repos/db/revs directory also shows file 360 to be there, as it should.
I just started to use trac, and I really like it, but Im directly stuck at this one. any help please? Dunho if the severity and priority is set ok, but to me it is. TRAC is pretty much unusable to me if I cant browse source,
Attachments (0)
Change History (6)
comment:1 by , 19 years ago
Severity: | major → blocker |
---|
comment:2 by , 19 years ago
Owner: | changed from | to
---|
comment:3 by , 19 years ago
Severity: | blocker → major |
---|
comment:4 by , 18 years ago
Sorry for the blocker thing, I actually put it back to blocker since I thought it would be less severe then major. Figured it _blocked_ a certain functionality, which is the repository browser, since its practically useless at the moment..
first off, in subversion itself, all works ok. Only trac shows the problem
Then, the location of the repository in the filesystem is /svn/asca. (We have multiple repositories stored in /home/subversion but its always accessed through a symbolic link in root: /svn. The one with the problem is /svn/asca)
about the repository, so you understand the way we set it up: we have multiple projects with multiple programmers. All projecs are located in /svn/asca/projects. each project has a systems library directory 'slib' which is a branch, located in /svn/asca/projects/projectname/trunk/slib. The trunk for the system libraries is /svn/asca/libraries/slib/trunk. All programmers make changs to their version of slib to fix bugs, add new functionality, etc. From time to time, all these changes are merged back into the trunk, and from time to time, a new stable trunk version is merges back into the projects so that everybody has these new changes.
The trac installation that has a problem is using /svn/asca/projects/andrade as a base repository path (I guess that would be repository_dir), so its not using the root of the repository. When I look in trac in /trunk (assuming the / root dir is /svn/asca/projects/andrade!) in the HEAD revision, all looks ok. As soon as I enter the sub directory /trunk/slib, I get the error
No changeset 360 in the repository
/svn/asca/projects/andrade/trunk/slib did not yet exist until revision 600 or so. It did exist in the repository, but only in the trunk /svn/asca/libraries/slib/trunk (which is outside the scope of the repository_dir). At revision 600 (more or less), all projects received their own branch of the slib trunk.
I hope this is clear enough.. if any other help is needed let me know..
comment:5 by , 18 years ago
just checked ticked 1839, and yeah, this looks pretty much the same. Any idea on when will 0.10 be released?
comment:6 by , 18 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Thanks for the clarifications. It's indeed a duplicate of #1830.
Concerning 0.10, I'd say you could already start to use it, as it's pretty much stabilized now. A beta should come in a few weeks, but several sites are using 0.10dev since some times already (e.g. TracHacks, this one).
At least, you should use 0.10dev for the /svn/asca/projects/andrade project, where you really need it.
Well, I have some difficulties to follow what's going on here. First start by giving explicit paths instead of the generic '/', '.', '..'. Also, mention what's your repository location in the filesystem and what's the
repository_dir
you're using, so that I can see if it's a scoped repository or not (there are some issues with scoped repositories in 0.9, in particular #1830, which can exhibit the kind of error you're reporting; those issues have been fixed in trunk for 0.10).And for the severity, we ideally would use blocker only if the issue is about an error that prevents any use of Trac in the general case.