Re: Another subversion dilemma
Re: Another subversion dilemma
- Subject: Re: Another subversion dilemma
- From: Christiaan Hofman <email@hidden>
- Date: Tue, 22 Jun 2010 11:06:00 +0200
On Jun 22, 2010, at 3:48, Joar Wingfors wrote:
>
> On 21 jun 2010, at 13.00, Matthew Weinstein wrote:
>
>> I now want to remove the old help folder and replace it with the new. The old folder is under subversion on a sourceforge server. How do I do this?
>
>
> Like has been pointed out already, every folder under SVN contains a hidden ".svn" directory that contains critical bookkeeping information. If you simply replace the files, leaving the folders in place, you should be good.
>
>
> On 21 jun 2010, at 17.28, Christiaan Hofman wrote:
>
>> Actually, deleting the files and the directory structure including the .svn directories is not really the problem. It's rather that Xcode's support for svn with /replacing/ folders is still buggy. In theory you should just be able to first delete the folder in Xcode (making sure you confirm to also remove it from SCM), then add the new folder to Xcode, and finally add it to the repository. The first two steps work OK, but somehow Xcode refuses to do the last step, which should be considered a bug in Xcode. It should work though of you first commit after deleting the old folder.
>
>
> The only issue that I know of in Xcode 3 related to this is that the default view in the SCM pane doesn't show folders that needs to be added to SCM. You can make it show folders though, by switching the SCM pane from "Flat" to either "Interesting" or "All" from the File List Filter menu (see the documentation).
>
That's not correct, there IS an issue with this. When I perform the actions exactly as I described, I get an alert telling me that it cannot find a particular file in .svn when I choose "Add to Repository" (which should be true because there is no .svn before it's added to svn) . And BTW I DO see the folder (at least the root), but it does not matter whether I use that folder reference of as you describe.
>
>> If you do the above from the command line, all works fine. Just "svn rm" the folder first, then copy the new folder in place and use "svn add" to add the folder (this is recursive). This is by far the easiest and quickest way for a large number of files and/or a deep hierarchy.
>
>
> That is rather bad advice IMO. A very important reason for using SCM is that it provides you with easy access to older versions of your files, and to the history of their changes. With your suggested approach, that history is for practical purposes essentially lost. You also point out the limitations of this approach, but I think that an additional warning is in place.
>
> I think that a better advice for beginner SCM users is to only do the "logical" SCM operations. You add the files that are new. You only delete the files that should be removed for good. You commit updated version of files that needs updating. Makes sense, no?
>
Well, that's also what I said. However for large folder (hierarchies), like often for help books, this can be extremely tedious. And it may just not be very relevant to keep history, because there may not even be any logical connection between old and new files with the same name (in the help book you often see a lot of files that are distinguished just by an ordinal number, which says nothing about the content, and can be redistributed between versions, so history is pretty much useless anyway.) So it depends on your situation, and if the history is very relevant. If it's not, as I said, replacing the folder is much much easier and less prone to errors (like forgetting to add/remove a file). Especially when you have subfolders (remember, you should replace these also!)
Christiaan
>
> Matthew: If you need to update these files for every release, you might consider writing a script that exports and copies the updated files in place from their sources. Investing some time into such a script up front would probably save you a lot of time and "operator error" mistakes in the future.
>
>
> j o a r
That's also good advice. It's what we do, starting from a texinfo source (which is plain text, and therefore good for history/diff and relatively easy to edit).
Christiaan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden