> 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.
You've never worked with artist have you? I also work in the games
business and use svn for our projects and it is a huge pain with
non-technical people. They have no idea what a command line is, so
everything has to be done though TSVN. They do not understand what
version control is, all they know if they have to use it (and yes, I
have tried and tried to explain it). For the most part version control
exists for the programmers, so this just slows down the artists.
I don't want to lump all artist into the same category, some of them are
great, but they are also the technical ones.
Ron
Ryan Schmidt wrote:
> 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: users-unsubscribe@subversion.tigris.org For
> additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Sep 4 05:58:43 2005