seems to be fixed now

cvs commit gives still /usr/local/tigris.... path when checking in

Is the echoed commit path an issue for any of your automated 
processes? My understanding is that the log path was critical. Is 
this issue breaking anything, or is it just annoying?

If just annoying, I'd like to downgrade to P3. Let me know 
otherwise and I will arrange a fix quickly. (I am trying to prioritize).

No, it's not only annoying.
There are tools which collect the file and rev of a just committed 
file.

Will begin resolution this morning. Kat, let's get with thom to 
patch this as he did with the log.

I saw that diff, update and other commands still display 
the /usr/local/...  path.

I think live will be much easier for all if cvs provides overall 
consistant paths to the repository for all cvs commands.

New summary to better reflect the situation.

Issue pcn5313 has been created internally for tracking.

The underlying cause of this problem is that the application 
uses a symlink between the 'symbolic' CVS directory (/cvs) and 
the actual location of the repository: the fully qualified Unix path 
you guys are seeing in CVS messages.

We are going to test a long-term fix to this problem over the next 
two days. If it is successful, we will need to stop the pserver on 
Wednesday or Thrusday for a period of less than one hour to 
update the OOo site.

Our long-term fix test did not work as expected.

Here is our new, more certain proposal:

Embedded within the CVS application code is symlink 
information. We propose to strip all this stuff out and put it into 
the CVS configuration .pl file.

This will solve the problem now and will make it a nonissue for 
any future upgrades.

The effort will take up to five days to code, stage and implement. 
Site downtime will be a matter of minutes at go-live.

I have already started the process rolling.

Apologies - the QA queue has caused me to push this one out 
again. I believe it will approximately two weeks before we can 
promote this to the OOo production server.

As we get closer, I will firm up the implementation date.

Hi,

A fix for this issue has been verified by QA in version 1.1 of
SourceCast and will be present in the upgrade to this version. 

Thank you
Kat

reassigned

accepting

Tested commit on staging server, the short path is returned:

[kat@localhost www]$ cvs -d :pserver:kat@localhost:/cvs commit
about.html 
Checking in about.html;
/cvs/www/www/about.html,v  <--  about.html

We will be testing other commands, please also provide feedback on any
you find are still returning the long path.

Thank you
Kat

on the staging box:

the cvs log output looks fine, but after "cvs co" the CVS/Repository 
file does not contain the full path, e.g. it should 
contain /cvs/util/sot/inc, but the content is util/sot/inc.

Hi,

The solution in place currently, and the one available for the
upgrade, is a workaround only. The long term fix to virtualize the cvs
path is much more involved and is being tracked separately as the
internal issue pcn5949 targeted for a later release.

We are investigating the change in the CVS/Repository entry through
issue pcn6508 internally.

Thank you
Kat

I noticed that the CVS/Repository files are fixed in the meantime. I 
assume that something has changed on your side ?!?

Hi Martin,

Nothing has changed on our side that I am aware of. The Repository
file when i co util/sot/inc (and other modules) from the staging
server still shows the module without the preceeding /cvs as you noted
previously.
Which module did you try this with and find different results?

Thank you
Kat

OK, here some clarification:

there are two valid possiblities for the CVS/Repository file:
1. the absolute path (e.g. /cvs/util/sot)
2. the relative path (e.g. util/sot)

If you mix up both kind of entries, things will not work.

if a cvs client 1.10.x is used for checkout, absolute path will 
generated, using cvs client 1.11.x is generating relative paths.

so, if somebody mix up these kind of clients (like I did), he will 
get into trouble.

the same behaviour is already in SC 1.0.8

As the original problem (/usr/local/tigris/data/helm/cvs/...) paths in
cvs command is fixed, we can close this issue. If we find new CVS
related issues we will open new bugs.

closed