No subject

[John Maher]

Just wanted to point something out.  I was following the book and now I am forced to lose 1 years of history and code changes in my repository.  There is no way around it.  I think the book should be changed to prevent further loss.  Most projects nowadays have binary files created by either the compiler or development environment (or both).  These should not be added to the repository.  If they are then they make doing a merge problematic proportional to the quantity of unwanted files.  It can make it cheaper to manually rewrite the new code then deal with all the conflicts.  I believe that this should be mentioned at least briefly in the section called:
Importing Files and Directories
You can use the global-ignores to fix this or an in-place import (which I have not tried).  Here is some information I got from someone on the subversion mailing list about in-place imports:

Instead of "svn import", I often prefer and in-place import. In this method, you first "svn mkdir" an empty directory in the repository where your files will go. Then you "svn co" this directory on top of your directory of original files, thereby transforming it into a working copy with unversioned files. You can then "svn add" files you want to import. If you add a file you didn't want (perhaps by running "svn add *") you can "svn revert" the file to essentially "un-add" it. You can "svn ps" to set additional properties. (Perhaps you want to set "svn:ignore" on some directories.) You haven't committed anything yet, except for the creation of the empty directory. You can continue to modify your pending commit as desired, using "svn st" as often as you like to inspect what will be committed, and finally "svn ci" when ready to commit it.



And as noted, your original directory of files has *become* the working copy, which is often what people want anyway.





The FAQ entry on in-place import is pretty limited, I concede. I assume that since it is a FAQ entry it is not in the book. I would like to see the in-place import method described in greater detail, in the book, replacing the FAQ entry.


If someone follows the book then chances are they will have a horrible time with any merge, never be able to do a merge or lose the original code and history from a tool that is supposed to preserve both code and history.  See the irony there?
If you would like me to type something up I would be glad to help.  I'd bet the author of the above passage would write up something about the in-place import if you needed.

Thanks
John Maher

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.red-bean.com/pipermail/svnbook-dev/attachments/20130813/c5f3ad6a/attachment.html>