I have a post-build script after building my c# project that will place one of the dll files in a specific directory. This dll is saved in SVN. My question is, is there a way that when building my project, it knows that this dll has not changed and would know not to be copied over to the directory so the there will not be a modified copy for the SVN?
A:
The quick and easy way is to stat both files and compare their modification times -- only copy the file if the DLL in the destination directory is older than the one you're copying.
A more robust but slower way is to use any number of diff programs to compare the two DLLs byte-for-byte.
Adam Rosenfield
2010-04-09 19:11:05
A:
Unless I'm misunderstanding your question, there's nothing you need to do. If the file isn't modified SVN knows this and won't commit.
Edit: You've clarified in answer to Tim that you're doing this to save other devs the trouble of building. This is the wrong way to do it. Source control should not be used to hold binaries that are output of the source. Instead you should:
- get continuous integration working on your tree
- send all output from 1. to a a common share
- tell all devs to look on this share if they don't want to build something
Nathan Kidd
2010-04-09 19:19:30
I am seeing a red "!" on the dll file every time I build the project. Do you mean that even though it has this red "!" mark, when I commit, SVN will not commit the dll file?
queandans
2010-04-09 19:40:48
Generally that indicates the file has been modified, so it means you'll get a new copy checked in. Keep in mind that even if you build the exact same source you'll get a (slightly) different binary every time (linker timestamps, code-signing timestamps, etc.) Note: If by "red !" you mean a Tortoise Overlay bear in mind that those overlays are not 100% accurate.
Nathan Kidd
2010-04-10 14:28:03
A:
Why are you putting dlls that you build into svn?
EDIT
You should figure out a better way to do this - like have an installer or an ftp server somewhere where developers can get your DLLs. It is a really bad idea to put your derived works into svn. Really bad.
Tim
2010-04-09 19:19:48
so developers in the same company can build plug-ins using this dll without getting all the source code and build it.
queandans
2010-04-09 19:43:32
that's not really a good way to do it. If they aren't building it then I would put builds/installs on a different server for downloading. Source control should probably be source. The only binaries that belong in svn are third party things that don't change.
Tim
2010-04-09 19:56:00
I agree with Tim. Having auto-generated files in the VCS can give you every kind of pain, because it is hard to find out which binary is "the right" one. The pain starts, when some developer checks out an old revision, builds the .dll and checks this one in. Now there is no indication in the VCS that the now newest .dll is really a old one.
Rudi
2010-04-10 15:08:53
A:
SVN should already take care of this for you. If there are really no differences between the files and you replace one with the other, SVN will not consider the file to be "modified," even if it has a new timestamp. SVN keeps around a base revision of the file and uses diff itself to see which files need to be committed. So you can just always copy the dll and SVN will take care of the rest.
Robert McIntyre
2010-04-09 19:19:56
A:
Try to commit anyway and see if SVN agrees with your graphical interface.
If it tries to commit anyway, then whatever is building the file really is including some different information every time (maybe a time stamp or something). You may want to actually commit since that file is different. You can check your compile options to see if it is including some sort of time stamp, but if you can't find such an option, it will be hard to tell if the changes to the dll are meaningful or just some compiler meta-data.
Robert McIntyre
2010-04-09 23:19:23
A:
It is OK to check in binaries into subversion. The reason for that is that the downstream user (QA or user) may not have the environment to build from source code. They are also not interested in building from source code.
The issue here is a building management issue - when you release that DLL, and how do you track back to the source if QA finds a problem with your DLL.
Timestamp is not a reliable method.
You need to have something in building management for this purpose. In my project, our building script locates the max revision number of the files involved (note that this is not the current revision number, as you should be able to build in the future but produce the same results). It then stamps this number to the DLL's version resource. After we are satisfied with the result, we release it by manually copying the binary into a folder in subversion and check in.
If QA finds a bug, we can always go back to the state that built the DLL (by looking up the version number) and find where the problem is.
Sherwood Hu
2010-04-16 19:30:43