Subversion

[Daryl]

What are these * .merge-left.r12 type files subversion keeps adding to my projects? What are they for, can I delete them or keep them from being created somehow? These are starting to get annoying.

[mike5]

These files are a product of merge conflict.

For binary files (which VIs are), you get rid of them in SVN approved way:

If you have conflicts with binary files, Subversion does not attempt to merge the files itself. The local file remains unchanged (exactly as you last changed it) and you have filename.ext.r* files. If you want to discard your changes and keep the repository version, just use the Revert command. If you want to keep your version and overwrite the repository version, use the Resolved command, then commit your version.

Br, Mike

[Daryl]

These files are a product of merge conflict.

For binary files (which VIs are), you get rid of them in SVN approved way:

If you have conflicts with binary files, Subversion does not attempt to merge the files itself. The local file remains unchanged (exactly as you last changed it) and you have filename.ext.r* files. If you want to discard your changes and keep the repository version, just use the Revert command. If you want to keep your version and overwrite the repository version, use the Resolved command, then commit your version.

Br, Mike

I dont understand why there should be a conflict. I am the only person working on this project so there is only one working copy and I commit my changes pretty regularly. What would cause a conflict?

[PaulL]

I dont understand why there should be a conflict. I am the only person working on this project so there is only one working copy and I commit my changes pretty regularly. What would cause a conflict?

An example: You modify a file (e.g., save a VI), then ask Subversion to do an update. Subversion will indicate that there is a conflict because your working copy is newer than the checked-in version.

[jdunham]

An example: You modify a file (e.g., save a VI), then ask Subversion to do an update. Subversion will indicate that there is a conflict because your working copy is newer than the checked-in version.

That's not right. You only get a conflict if your working copy has changed and the server copy has also changed independently (you or someone else committed a change from a different working copy). If the OP is the only one using the repository, there is something wrong with his workflow.

Daryl, do you have more than one working copy on your hard drive? There is no limit to the number of identical copies you can check out, and if you change them separately you will end up with conflicts. Can you tell us a bit more about exactly how you are modifying and committing files?

[PaulL]

That's not right. You only get a conflict if your working copy has changed and the server copy has also changed independently (you or someone else committed a change from a different working copy). If the OP is the only one using the repository, there is something wrong with his workflow.

Yes, you are correct. My example was not correct.

[Daryl]

That's not right. You only get a conflict if your working copy has changed and the server copy has also changed independently (you or someone else committed a change from a different working copy). If the OP is the only one using the repository, there is something wrong with his workflow.

Daryl, do you have more than one working copy on your hard drive? There is no limit to the number of identical copies you can check out, and if you change them separately you will end up with conflicts. Can you tell us a bit more about exactly how you are modifying and committing files?

I have a repository on a network drive that I created at the start of this project. I am the only person who has ever had a working copy, and I only have 1 working copy on my local hard drive. I commit changes on a regular basis and I dont believe I have ever done a "revert" , it is possible I may have done an "update" at one time but I am not sure. I always make sure that I end each day with all changes committed so I can start the next day "all green".

Currently, everything is up to date in the repository and I will not need to merge, revert, or update so is it ok to delete these merge files?

[jdunham]

I have a repository on a network drive that I created at the start of this project. I am the only person who has ever had a working copy, and I only have 1 working copy on my local hard drive. I commit changes on a regular basis and I dont believe I have ever done a "revert" , it is possible I may have done an "update" at one time but I am not sure. I always make sure that I end each day with all changes committed so I can start the next day "all green".

Currently, everything is up to date in the repository and I will not need to merge, revert, or update so is it ok to delete these merge files?

Yes, I think you could delete them. They came from the repository so even if it turns out that there is something you overwrote and is missing in the current version, you could go dig the older version out of the repository.

At some point if this keeps happening you need to look at what you are doing wrong, because this should never happen with the setup as you describe it. You should be able to do "update" as often as you like, and it should never actually do anything. It wouldn't hurt to do an update right after every commit, but again it shouldn't have any effect. The benefit is that you should find out sooner rather than later if something is screwed up about your setup or your workflow.

Good luck!

[Daryl]

Yes, I think you could delete them. They came from the repository so even if it turns out that there is something you overwrote and is missing in the current version, you could go dig the older version out of the repository.

At some point if this keeps happening you need to look at what you are doing wrong, because this should never happen with the setup as you describe it. You should be able to do "update" as often as you like, and it should never actually do anything. It wouldn't hurt to do an update right after every commit, but again it shouldn't have any effect. The benefit is that you should find out sooner rather than later if something is screwed up about your setup or your workflow.

Good luck!

Ok thank you. I will take a better look at my workflow when I get some time, I just kind of jumped right into Subversion without spending a lot of time studying or thinking about it up front. I just needed a quick solution and thought I would figure it out as I go.

One other question I have is what do you do with a working copy when you are done with it? Do you just delete it from your hard drive like you would any other (non versioned) file/directory or do you have to do something special so the repository knows whats going on?

[PaulL]

One other question I have is what do you do with a working copy when you are done with it? Do you just delete it from your hard drive like you would any other (non versioned) file/directory or do you have to do something special so the repository knows whats going on?

When you are "done with" the working copy, yes, you can just delete it from your hard drive using, for example, Windows Explorer. You don't need to tell Subversion anything.

Note that you can have multiple working copies on your machine.

In practice, I have a main working copy that I continually update, so I am never "done with" it.... (I do have temporary working copies of some packages occasionally.)

Paul

[Daryl]

When you are "done with" the working copy, yes, you can just delete it from your hard drive using, for example, Windows Explorer. You don't need to tell Subversion anything.

Note that you can have multiple working copies on your machine.

In practice, I have a main working copy that I continually update, so I am never "done with" it.... (I do have temporary working copies of some packages occasionally.)

Paul

Great, thanks again!