Hi All,
Please do let me know how to write the below commands in subversion
1) How we can commit a file in chunks. 2) Attaining lock on all files before we commit.
+1
A:
1) That's not possible. Either all modifications in a file are committed or none. You can't just commit part of the modifications in a file.
2) would be possible. But I'm not going to tell you how: the question clearly shows that you either don't understand how SVN (or version control systems other than VSS) work, or (in case you do) that you have a work flow that's broken and you're trying to misuse version control to fit that broken workflow. You don't need to lock files before a commit, and especially not all files. Just commit and you're fine. Locking is only for files that can't be merged (binary files), and even for those shouldn't be used lightly.
Stefan
2009-11-23 11:33:08
Thank you for the answer. I think i would have given more explanation for the above 2 commands.We are moving from MKS to subversion. Once the build is done, compilation is successful, all the compiled output(DLL,EXE) need to be checked into subversion.6 big folders are present. I am not able to commit as we have macfee as antivirus. If i commit all the folders at a time, iam getting the error (access denied). So i need to commit a files in a folder by folder.Before committing the compiled DLL, exe , there should be a lock for it.
soni
2009-11-23 14:03:51
If you keep binary files in your SVN repo, you're going to have a lot of issues every time you update, as SVN will be unable to merge them. Essentially, you'll have conflicts every time those files change, and you'll have to go in and manually resolve them, creating a lot of work for yourself.
notJim
2009-11-23 22:04:13
+2
A:
This is based on your original question and on your comment on Stefan's answer (was too big to fit in the comment box).
1) Subversion uses atomic commit operations, so committing a file in chunks is not possible.
2) With enough Subversion kung-fu you can do this (depending on the details of your setup), but you would essentially be shoehorning Subversion into acting like your old repository when the two are designed around different philosophies. This problem reminds me very much of what my team went through on a recent switch from VSS to Subversion.
The obvious answer here is to not check compiled objects into the repository. Version control systems are designed to store the source code that generates the binaries, not so much the generated binaries. One of the reasons that this is giving you problems is that it is not the type of thing that Subversion was designed for. I recommend the official book on Subversion which you can get freely at http://svnbook.red-bean.com/. You don't necessarily have to read the whole thing, you will learn a lot from even a cursory reading of the first 2 or 3 chapters (as far as technical documentation goes, the book is extremely easy to read). The work flow/philosophy of your old revision control system isn't entirely compatible with that of Subversion (not that one or the other is good or bad, only different), and I think the book does a very good job of explaining this very case.
If you are just trying to archive a copy of the compiled output, you will be better off loading up the binary files you need into an archive (zip, tar, gzip, etc) and storing this archive on a file server. If you need to be able to match a source code revision with the binary output easily, you can name the archive or the folder containing the archive with the revision number of the code used to generate it.
All that aside, if your antivirus program is causing problems then try adding the directories where you keep your source code to the antivirus program's ignore list. Typically speaking, these folders will only have source code files or binaries that you have created and can usually be regarded as virus-free (unless you're writing viruses, but that's another problem entirely).
bta
2009-11-23 21:59:59