On Sep 2, 2005, at 09:10, Gregg Tavares wrote:
> Now lets say they want to make Ogre-Commander which is the same Ogre
> with a few things changed. So, doing the natural thing, they copy the
> folder. They go to Windows Explorer, select the folder "Ogre", copy
> and paste, then rename it "Ogre-Commander" and proceed to edit.
The user needs to be educated to not do that. A version control
system is not a transparent entity. It requires the user to
understand what is going on, and to slightly modify their behavior.
The user needs to inform Subversion that he intends for there to be a
copy. For example, "svn copy Ogre Ogre-Commander" on the command-
line, or you can useTortoiseSVN since you're on Windows. The
additional advantage of this is that Ogre-Commander then becomes a
"cheap copy" of Ogre. If it's an exact copy, the repository size
grows by only a small constant amount. If one file in Ogre-Commander
is slightly edited, then the repository grows by the size of the
change only. If you were to just manually copy the original folder
and import it, Subversion would not know that it was based on (or
identical to) another folder already in the repository, and would
have no choice but to store it anew in the repository in its
entirety, wasting space.
> It would seem like the arguably best though I'm sure unpopular
> solution would be to stop storing whatever data is in the .svn folders
> locally in each versioned folder. Put them in local database keyed on
> the folder name OR put them in a semi mirrored folder tree stored in
> like "application data\subversion"
The reason the .svn directories appear inside each directory is that
it creates the nice property that each directory is a self-contained
working copy. You can rename your working copies, and nothing breaks.
You could move Ogre's Models directory out of the Ogre working copy
to somewhere else entirely in your filesystem, and it would still
know, through its .svn directory, how to interact with the
repository. The way the .svn directories work right now has all sorts
of nice consequences that I think nobody will be too keen on giving up.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Sep 2 11:44:03 2005