I'm assuming he's talking about simply using Windows Explorer to
drag-n-drop copy the directory, then renaming it. This would make a new
directory called "Copy of Ogre", which would be renamed, with all of the
content (including the .svn directories, which is the problem).
When I've done a copy like this in the past, I just delete the .svn
directories. One option you have is to export the Ogre directory into an
Ogre-Commander directory. After exporting, you would have to go thru the
normal add-commit routine. The immediate problem I see with this is that
you'd have to export the directory contents and not the directory
(exporting a directory will create a directory with the same name).
Outside of these two options, the only thing I could imagine doing was
allowing the option to convert a checkout to an export (removing .svn
directories for you).
Oh, and one more issue: When you do a copy-paste in this manner, Svn
doesn't recognize the fact that you have two directories with the same
information except different directory names (i.e. copy-paste "Ogre" to
"Ogre-Commander", both have the same .svn directories so Svn syncs them
with the same repository location, "/Ogre"). I'm not sure if there's a
way around this, but I do know that I'd hate to be forced to use the
exact same top-level checkout names as are in the repository. If I want
to checkout "repo/trunk/Ogre" to "Elf", I should be able to do that;
however, I'd think that keeping subdirectories the same would be
beneficial (i.e. "Ogre/Textures" would be "Elf/Textures").
From: Joshua Varner [mailto:firstname.lastname@example.org]
Sent: Friday, September 02, 2005 10:54 AM
Subject: Re: .svn folder needs to go away?
On 9/2/05, Gregg Tavares <email@example.com> wrote:
Now lets say they want to make Ogre-Commander which is the same
with a few things changed. So, doing the natural thing, they
folder. They go to Windows Explorer, select the folder "Ogre",
and paste, then rename it "Ogre-Commander" and proceed to edit.
The problem is that copy operation also copied all the .svn
and now svn is effectively messed up for them and they have to
some techincal person to fix this for them.
It would seem like the arguably best though I'm sure unpopular
solution would be to stop storing whatever data is in the .svn
locally in each versioned folder. Put them in local database
the folder name OR put them in a semi mirrored folder tree
like "application data\subversion"
There is work going on to allow working copies to not have a text-base,
don't think that is sufficient for what you need. That's an interesting
that probably should be supported.
I think it should go into the issue tracker. I'm not sure how to fix it.
Did the user
svn add the folder after making the copy? Did that fail? If so then this
is a bug.
What client were they using? Maybe that should be a client supported
in a GUI?
I, also, didn't see any open bugs for this.
Received on Fri Sep 2 18:20:40 2005