Stefan Küng wrote:
> We've released TortoiseSVN 1.5.0-alpha1.
I have a question about how sparse directory support is going to work.
Our users are not very technical, so we've gone the route of one large
repository for all of our client projects (8GB with a few thousand
revisions after a year). This greatly simplifies a lot of things from
an admin side because we can setup a working folder (typically
"C:\Our\Jobs") and checkout everything to folders underneath that point
(from svn+ssh://svn.example.com/our-jobs).
Right now, we checkout the entire repository for each user. The
advantages of this method are:
- "svn up" can be scheduled to run at 3am and will update everything,
which means less confusion about whether or not what is on the local
working copy is up to date or not. It also allows people to look at
another project's files immediately without having to wait on transfers.
And if they do need to update a project mid-day, the odds are high
that the transfer size will be minimal.
- Less confusion for the end-user. They know that if they want to look
at job XYZ, it's always going to be in the same place. Some of our
users still don't grasp the concept of drive letters or URLs.
- Because we use TSVN as our primary interface, it's easier for our
users to be able to right-click on the working copy root folder to get
where they need to be when using the repository browser. So having a
pre-populated working copy makes it easier for them to look at the
change log for a particular area without navigating through the
repository browser.
The downsides are:
- More space used on the local hard drive. Not a big deal as we have
planned for that when we ordered new systems.
- Lengthy updates. It can take 15-20 minutes to churn through all of
the folders when doing an update to the entire working copy. Which is
why we schedule the "svn up" to run at 3am each morning. It takes a
long time to work through 200,000 files and 80,000 folders (which is not
a TSVN drawback, that issue is an SVN issue).
- Folks end up with stuff on their hard drive that they really aren't
immediately interested in. On the other hand, due to the nature of our
work, we frequently have to help someone else on a project that may not
have been expected. So having everything is useful.
With all that being said, I'm thinking about how sparse folder support
is going to change how we work. Obviously, it could mean that it's a
lot easier to only pull down projects for clients that are directly
under our purview. Or to only pull down jobs for the current year (one
of our repositories is organized by year, the other is organized by
client). So here's a use case that I think might happen:
1) We create the C:\Our\Work folder and checkout the /our-work
repository to it. But we tell TSVN/SVN to only pull down the root
folder, perhaps with a depth of immediates.
2) The user then right-clicks on C:\Our\Work and goes to the repository
browser because they want to fetch a project. Ideally, the TSVN
repository browser would remember that C:\Our\Work was the starting
point for this browse session.
3) The user drills down in the repository browser to
/our-work/A/clientA/jobXYZ and tells TSVN to fetch that folder and all
sub-folders.
4) The default path for this operation would ideally be (but the user
could override it if they wanted):
C:\Our\Work\A\clientA\jobXYZ
5) So TSVN would pull the content down, creating all the intervening
folders with the appropriate "depth=" flag. So that doing an "svn up"
from C:\Our\Work would still work correctly.
The hard part is #5. Walking from the root of the browse session down
to the folder that was actually wanted. Figuring out which depth flags
to set on the way down so that there is still only a single working copy
under C:\Our\Work.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-03-03 16:37:32 CET