AccuRev plug-in server side checkout does not work with long paths

Hi,

I am working on windows platform where a filename (inluding full path) normally can be no more than ~260 characters.

In this environment, when using AccuRev GUI to populate a workspace where the combined path and filename with workspace path is exceeding this maximum limit, then AccuRev just crash and does not populate properly. For the GUI the workaround is to rename the workspace path to be shorter so it can be populated in a path which does not exceed the limit.

When using the AccuRevg plug-in to do server side checkout, this is problem. As far as I can detect, it is only possible to define the agent side path but not the temporary path for the server side checkout. So I can see that it defaults to something like "C:\TeamCity\temp\accurev23658965311886311583148321255833" (some kind of random digits of very long length). This means that my temporary folder easily exceed the maximum limit even though my agent path won't. This means that I cannto use server side checkout and I am forced to used client side checkout, which in my case means a lot of installations of AccuRev on each build agent.

Is there anywhere this temporary folder can be defined today so I can use a shorter path?

If not, can the plug-in please be updated with such feature?


Thanks,
John Ray

6 comments
Comment actions Permalink

It look like the path is hardcoded.
Can you switch to agent-side checkout?

0
Comment actions Permalink

Hi,

Yes it works when I do agent side check-out, but as mentioned in my original post this requires quite a lot of AccuRev installations, one per agent.

Because of this it is not a very good option. It will cause a lot of maintenance for us and some features such as excluding directories cannot be used.


Regards,
John Ray

0
Comment actions Permalink

That's 3rd-party plugin, so JetBrains does not maintain it.
You can try to contact an author, or get sources and fix it directly.

0
Comment actions Permalink

Thank you for your reply.

I read the post you pointed to before and since I am using same forum I thought the authors would read my post as well (eventually). I am no fan of mixing multiple topics in one thread, that is why I started a new thread. However, your reply indicates that it may be better to post my question to exsisting thread instead and I will do so.

Regards,
John ray

0
Comment actions Permalink

Hi John,

Apologies for the delay in responding (FYI I received notification of your issue via the other thread).

Looking at the plugin source code, I noticed that uses a JetBrains API to create a temporary folder, appending the AccuRev transaction ID as a suffix (the toVersion parameter):

     File tempDir = FileUtil.createTempDirectory("accurev", toVersion);


It's possible that txn ID is making the dir name unnecessarily long (interestingly, my temp dir names are 6 digits shorter than yours) . Can I ask what your highest AccuRev txn is at this moment?

If the suffix isn't needed I could issue a patch with this taken out. Hopefully that will satisfy the windows dir length restriction.

Regards,
Daniel
0
Comment actions Permalink

danere wrote:

Looking at the plugin source code, I noticed that uses a JetBrains API to create a temporary folder, appending the AccuRev transaction ID as a suffix (the toVersion parameter):


     File tempDir = FileUtil.createTempDirectory("accurev", toVersion);


It's possible that txn ID is making the dir name unnecessarily long (interestingly, my temp dir names are 6 digits shorter than yours) . Can I ask what your highest AccuRev txn is at this moment?

If the suffix isn't needed I could issue a patch with this taken out. Hopefully that will satisfy the windows dir length restriction.


Hi,

My tempname was not having the exact digits from my real system, my idea here was to show that it was a very long path causing the problem. My temp path is "C:\TeamCity\temp\accurev" + some 20-30 digits. But even without the digits the path would be to long!

My folder structure (including filenames) in Accurev already today is at maximum ~245 characters. And since maximum path in my windows system is ~260 characters it means that there is only some 10-15 characters left for the root workspace folder. When we do manual checkout we have defined to use "c:\ws" as our path and thus we have not seen this problem until we started to use this plug-in.

The solution to my problem is not to generate less random digits. But if I could have an option to define the temp path root (complete path; both the first static part as well as the ending random digits part), then I can define a path that is short enough to work fine.

(I do not see how this can matter, but since you asked for it...My current maximum transaction id is 649 365.)


Regards,
John Ray

0

Please sign in to leave a comment.