You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Gregg Tavares <gm...@greggman.com> on 2005/09/02 07:10:12 UTC
.svn folder needs to go away?
I was wondering if this has already been addressed. I didn't see it
in the issue tracker but then I might have missed it.
basically the issue is this. Now that svn is being used more and more
to manage art assets it is in the hands of less technically savvy
users. Those users, especially on Windows, don't know all the rules
they have to follow. So for example, (I'm in the game industry).
Let's say an artist has a folder structure like this
Ogre
--Models
--Textures
This folder is versioned by svn.
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 problem is that copy operation also copied all the .svn folders
and now svn is effectively messed up for them and they have to go find
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 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"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: .svn folder needs to go away?
Posted by Joshua Varner <jl...@gmail.com>.
On 9/2/05, Gregg Tavares <gm...@greggman.com> wrote:snip
> 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 problem is that copy operation also copied all the .svn folders
> and now svn is effectively messed up for them and they have to go find
> 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 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"
>
> There is work going on to allow working copies to not have a text-base,
but I
don't think that is sufficient for what you need. That's an interesting use
case
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
behavior
in a GUI?
I, also, didn't see any open bugs for this.
Josh
Re: .svn folder needs to stay
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 3, 2005, at 10:55 PM, Ron wrote:
>> 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.
"Artists", then, are the perfect audience for svn's autoversioning
feature. Let them all mount the repository as a network drive, copy
stuff to local disk, edit away, then copy back. Or, let their
applications open the artwork directly from the network drive; the
operating system will automatically lock the data until it closes the
files.
That's truely transparent version control.
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: .svn folder needs to stay
Posted by Ron <li...@rzweb.com>.
> 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
Re: .svn folder needs to stay
Posted by Ryan Schmidt <su...@ryandesign.com>.
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