I don't like AccuRev

A company I have been contracting for decided to use AccuRev as its source control solution. I've not liked it from the start because it is too much work, the terminology in it is quite frankly stupid, and it is far too "chatty" when you work remotely.  Anyway, for some time now I have suspected it has been losing source code. On a few occasions I have found myself looking at source code and thinking "I could swear I have already done this!".

Well, last week I wrote some pretty nice code which used multiple threads in a test case to ensure I experienced expected behavior when multiple users update the same objects in a database.  Today one of the other programmers said to me "Didn't you write more tests than this?" and showed me the tests.  My multi-threaded tests were gone!

I knew it all along, but now it is indesputible, AccuRev has been losing my work!

Comments

Unknown said…
Hi Peter,

I'm sorry about your feelings toward AccuRev, but we'll leave that aside for now.

As for AccuRev "losing work" and your ability to prove that, we'd be very interested in seeing evidence of that since it's really not possible. Please feel free to contact me at 781.325.0666 so that we can examine this.

Cheers,
James Talbott
Senior Systems Engineer, AccuRev
"and your ability to prove that" - So am I on trial here or something? Can whatever I write be taken down and used in evidence against me?

I like the "it's really not possible" statement. The only bug-free computer program I have ever seen was called "Hello world".

As for providing you with information which might help to solve the issue I'd be happy to. I will ask my client if they would be happy to provide you with information as it is obviously not my place to do so.
Unknown said…
Peter, I apologize if my comments were taken in a "trial lawyer" sense. That was certainly not my intent. I merely meant to communicate that while I won't deny AccuRev can have bugs, the very nature of our product ensures that you can't "lose" information. There isn't a single documented case of this ever happening. So while I can appreciate the Hello World analogy, we're as close to that as possible.

By "prove that" I mean that if you can show evidence of AccuRev losing work, we would be very interested in seeing it. Please convey those sentiments to your client and also feel free to provide them with my contact info.

Thanks,
~James
Dave said…
Hi Peter - I've been using AccuRev for over 5 years on very-large projects (500+ users) and never had any problems as you describe.

I ~can~ think of only one situation where accurev doesn't think you have any changes to files -- timestamp optimization. By default, accurev only checksums files that have newer timestamps [checksum'ing unnecessarily is expensive]. The checksum is used to determine if the file is modified. So if your file is NOT getting a new timestamp, that file will not be kept if you do a bulk 'keep -m'. For example, I work all day and before going home do a blind 'keep -m' to keep all my modified files... this would miss any timestamp problem files described above. Solution below:

If you suspect this, you can override the optimization in the CLI with '-O' (big-Oh) or a checkbox in the gui workspace. A quick check with 'stat -m' compared to 'stat -m -O' will give you evidence of this effect. I'll say that this is rare and usually only happens when you unpack files with tar/zip and the timestamps are older than what is on your box.

HTH _ dave
Hi Blottfish.

You certainly did come across in a challenging way rather than "let's look into what happened".

In this case I believe I can remember the steps:

01: I checked in
02: Somebody couldn't do a build
03: I added some new files I had missed
04: I deleted my local files
05: I did a recursive GET from the server
06: It wouldn't build for me either
07: Someone else checked in some binaries (microsoft patterns)
08: I did an Update
09: AR told me that my files were in conflict
10: As they were MY files that had existed for a long time and I knew they had not changed I assumed it was some kind of file date problem or something and told AR to merge them
11: I got some error window (trying to get a copy back of a colleague)
12: I did a "Revert to most recent version" - Should be what I last uploaded successfully
13: Someone later discovered that the changes had been removed by the checkin I did in step 10.

Now seeing what Dave has said in his comment, if it is true then it could be possible to check in work, think AR has the changes, then wipe your local copy and grab what is on the server. Although the changes wouldn't be lost by the server they would be lost as a consequence of the AR not sending all changes to the server.

However this isn't the case here because the server has my previous version + a newer version with the changes removed.

I can't connect to the VPN at the moment because I am downloading 4GB of files which will take until tomorrow, but I will see if I can get someone from my client's company to contact you.
Unknown said…
Hi Peter,

I had the same problem and I can tell for sure it was due to the 'timestamp optimization' feature. The hell is you have to remember to disable it every time you open AccuRev...

I hope they fix it or my company moves to a better (and possibly cheaper) product.

Cheers,
Rodrigo
Thanks for the comment!

I knew I was right because of the data that was on the AccuRev server.

The guy from AR who wrote to me publicly to say they would be happy to sort it out....in private they did absolutely nothing. I wrote to them and they just said "Nothing to do with us, you need to find the right department" - so much for the offer of looking into it on my behalf.
Unknown said…
Clarifications:

Publicly I said I'd be happy to help, privately we had a multi-email thread discussing the matter as well as a phone call. Peter was indeed referred to our excellent Support organization to investigate the specifics of his issue, but no case was ever filed. In fact, over the course of almost two years, there have only been a total of 5 cases raised by their organization. Really hard to characterize this as doing nothing or not looking into it on their behalf.

Rodrigo: Timestamp optimization is indeed a feature, and an incredibly valuable one. There are well documented situations where you would want to turn it off temporarily. Optionally, you can turn it off by default, although this would not be the recommended course of action for the vast majority of users.

Regards,
James Talbott
Senior Systems Engineer, AccuRev
We discussed it, you said I should talk to support and gave me a contact.

I wrote and asked what they needed for help to work out what went wrong, and I was told that I should not contact the person you referred me to. In fact not only would that person not be able to help me, but someone from the customer's site would have to contact their own support representative.

So basically the offer of looking into it amounted to
"Get a guy at the office to phone your local support and ask for help" - so although your offer of help was appreciated it was also fruitless.
Unknown said…
With ERP software, the first task the value proposition or why you need a new system in the first place is key. Build an appropriate value proposition for the ERP system based on a number of considerations. Obviously the first consideration is the results of your assessment. However, there are a number of other key considerations which must be kept in mind including the target audience, the drivers/motivators of the target audience, etc.
For more information about erp products and its reviews please log on to www.erp.com
Derek WIlliams said…
I know this is an old post, but I've seen the same thing happen, even with timestamp optimization turned off. I believe it is related to the convoluted myWorkspace, MyWorkspace stream relationship. I didn't even realize that existed, so my changes were on my local machine, and shown as backed, but my workspace stream did not have the changes. I really don't like Accurev either.

Popular posts from this blog

Connascence

Convert absolute path to relative path

Printing bitmaps using CPCL