Kumaran,
I look forward to your patch, and tend to agree with your assessment
about non-power users being confused by the .svn directories in the
working path. However, I don't think that's a big reason to make such a
fundamental change to the software.
I do have another use case for you, though. The discussion has pointed
out that a shared workspace is only possible with the .svn dirs in the
wc. However, if you're working with people who don't have a clue about
SCM, removing these directories would be a great solution.
My use case is managing web sites. I have plenty of disk space for
developing a web site, but on the production server, I don't want to cut
my effective disk space in half--there's no need. I build web sites for
clients, and sometimes they make changes to various pages, and this
causes all kinds of problems trying to manage these changes in
Subversion. Here's what happens (now):
1. I download a web site to my development server, and import into
Subversion.
2. Because I can't convert the existing copy to a wc, I now have to
check it out somewhere else to actually work on it.
3. I make my changes, using Subversion normally, on my server (where I
can use a web-enabled directory as a WC). After my client approves, now
I have to post it.
4. I export the tree to a clean directory, and sync with the end server.
Not too bad, but now here's the big problem:
5. My client makes some changes to their web site directly.
6. They ask for more help. Now what do I do? I have to download their
site again/or use some other tool to synchronize with an exported
version of the site.
7. Then I have to manually merge all the changes back into my working copy.
8. Work on it again, then export, then repost.
Argh! All these cool, automatic merging features in Subversion become
utterly useless for a couple steps in here. At least the recent changes
about restoring the commit date to the files, rather than the export
date should save some of the synchronizing with the web site, but what a
pain.
With your patch, I should be able to do:
1. Download web site, import into Subversion.
2. Check out WC to web server.
3. Make my changes.
4. Sync WC directly with production server.
And then, after the client makes changes, all I have to do is sync my WC
with the public site, no more import/export and manual merging!
I've been using Subversion since February, and have yet to move a WC. I
have put a WC on a network share, and checked in/out from multiple
machines, but I could easily give up this functionality for web
projects, where the current deployment situation is such a hassle.
So now, my question would be, would your patch support choosing
different options for different WCs? Could I put my web and
configuration repository metadata in the single .subversion store, and
then check out (and continue to use) a different WC with embedded .svn
dirs on the same computer? I'd rather this be a configuration option
associated with a WC than a machine, perhaps with an additional setting
for the default behavior for new WCs.
Cheers,
John Locke
Freelock, LLC
http://www.freelock.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 27 22:49:51 2003