Stefan Küng wrote:
> Thomas Harold wrote:
>
> [snip]
>> - "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.
>
> What happens if there is a conflict in the automatic update?
From what I've seen, "svn up" will bring down the conflicted file as a
new filename. So if you have foo.txt, you'll end up with foo-rNNNN.txt
as well. Before you can then do a check-in, you'll have to resolve the
issue manually, but the svn update is very safe from our experience.
For our users who are not in the office (connecting over slower lines),
running the update in the middle of the night means less waiting in the
middle of the day when the clock is running. It has also resulted in
less frustration because they forgot to do a "svn up" before they
started working on a project.
>
> [snip]
>> 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
>
> No, that path can't be overridden. Sparse directories doesn't mean that
> you can arrange your working copy as you like. The paths still match the
> ones in the repository. Sparse directories only means that some
> directories can be missing in your working copy.
My (incomplete) thought there was that there are (2) cases:
1) The normal case where they want to bring down a section of the
repository via the repository browser and have it show up under the
existing working copy at the right place. They wouldn't be able to
override the decision in that use case.
2) The user is browsing the repository, but really wants to create a new
working copy instead of bringing it down into the existing working copy.
They just got to the repository from an existing working copy out of
convenience.
What I'm not sure is whether case #1 would use the r-click, Checkout
option in the repo-browser, or whether it would have its own command.
In 1.4, the checkout dialog leaves the "Checkout directory" blank by
default. In 1.5, I'm wondering (if use case #1 uses the "checkout"
dialog) whether the "checkout directory" could be pre-filled automatically.
(I need to go look at the 1.5 betas for both TSVN and SVN and find a box
to test it on to see how it works. I've been thinking about how I'd
like to work for a few weeks now and figured I'd jot it down. Most of
my understanding is based off of the 1.5 sparse directory document put
out by the SVN team.)
---------------------------------------------------------------------
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 18:41:58 CET