On Nov 26, 2010, at 01:58, Ewgenij Sokolovski wrote: >> I believe he's thinking of "svnput" whose source is here: >> >> http://svn.apache.org/repos/asf/subversion/trunk/tools/examples/svnput.c >> >> Or you could probably write something equivalent using any of the language >> bindings. > > I looked at the file. Did I get it right that it just puts a single file into > repository,
Yes, it puts single file(s) into the repository, overwriting any file that may already be there in the repository with that path/name. > but it does not enable any tracking of the changes on the file at its origin? Yes, it does not create or use a working copy on the client. If you make changes to your file again later and want to send it to the repository again later, you run the same svnput command again later. > So, for example, if I put the file /home/Ewgenij/test.c into the repository > this way and edit test.c then, the repository will not take notice of this > editing during the next commit, right? It's not the job of the repository or the Subversion server program that manages the repository to "notice" anything on your client computer. Typically, you will have a working copy on your client computer, and run a normal Subversion client program to use commands like "svn status" to see what files are changed, "svn diff" to see what the changes are, and "svn commit" to transmit those changes to the Subversion server program so they can be recorded in the repository. A typical Subversion client program would alert you if there are changes in the repository that conflict with the ones you're about to make, and require you to first integrate those changes into your working copy before letting you try to commit again. svnput is an alternate (and greatly simplified) Subversion client program that excludes all that functionality and simply transmits your file to the server which writes it into the repository, regardless of any conflicts that might otherwise arise. There are a few situations where this may be useful, but it's not a good way to work with the repository most of the time since it's a great way to overwrite other peoples' work in the repository (though not irrevocably, of course; all history is recorded forever in the repository and can still be retrieved).
