Ryan Schmidt wrote:
> I don't understand why you want the intermediate folders. What's wrong
> with something like:
>
> svn co $REPO/X/XYZ X-XYZ
>
> ? I often did this for our repository which also had a client>project
> hierarchy.
For a few reasons.
- Maybe I go back later and need the intermediate folders. Due to the
way that SVN (and TortoiseSVN) work, having the folder structure in
place in my working copy makes that much easier. (The desire for a
folder-only checkout or update is so that we have a workaround for the
inability to do a deep and selective update.)
- I work with less technical users. It's much easier for us to setup
the base checkout of C:\Work and then let all of the working copy
folders simply fall where they match the repository layout. Over the
long run, having the working copy layout match the repository layout
causes us a lot fewer issues. The users that want to get fancy can
still get fancy, but most people will simply mirror the repo structure
because they find it less confusing.
- Less technical users like consistency. Being able to tell someone
that project XYZ will, by default, get updated to location
C:\Work\Jobs\Clients\X\XYZ because a bit of shared knowledge for the
userbase. Things then work in (what they consider to be) a sane fashion
and there's fewer questions or blank looks. Under VSS, you would set
the working folder at a level in the repository tree and all folders
underneath that point would automatically download to locations relative
to that setting. (Usually, you'd just set a working copy for the root
folder, but you could also get fancier.)
- Multiple checkouts are complex and a time cost. "What do you mean I
have to create another working folder and do a new checkout? Why can't
I just pull down that X/XYZ folder into my existing working copy?"
Being able to do a deep, selective update within a working copy allows a
user to grab just what they need so they can look at another user's
project quickly. (Our primary users work from home offices, in
different states. It's not as simple as walking over to the next
cubicle and looking at the other user's existing working copy.)
- With multiple checkout points, we can no longer go to a user's C:\Work
folder and do a large scale "svn diff" to see if they've forgotten to
commit a change to the repository. Having multiple checkout points
under C:\Work would cause issues (no?) with this ability.
- Some applications in Windows / OS X choke horribly if related files
are not at the exact same path location. The usual culprit is MS Access
where you link to other MDB files in the same folder. This information
is based on the absolute path of your working copy, so if another user
has a different working copy layout, they'll have issues when they try
to look at that MDB's linked tables. Either their working copy layout
needs to match everyone else's or you get into a constant battle where
everyone is changing where the linked tables are pointing to.
...
(Apologies to the list if I sound a bit repetitive about this. SVN is
the best version control system that we've found. The TortoiseSVN
product is extremely easy to use and powerful. But for us, it's this
one little use case that is causing the most pain during the migration
away from SOS/VSS. It's something that we run into multiple times per
day, especially when we're in crunch mode and working on a dozen client
jobs at the same time.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 25 15:20:41 2006