cmpilato@collab.net writes:
> Dammit, the very fact that you ask this reminds me that I forgot to
> write up the explanation.
:-)
Good explanation; maybe it should live in the code, near where the
tweak is done to the target list...?
-K
> Here's the short version:
>
> 1. Disclaimer: if you wish to debate the following, talk to Karl. :-)
> Order matters for updates because a multi-arg update is not
> atomic, and CVS users are used to, when doing 'cvs up targetA
> targetB' seeing targetA get updated, then targetB. I think the
> idea is that if you're in a time-sensitive or flaky-network
> situation, a user can say, "I really *need* to update
> wc/A/D/G/tau, but I might as well update my whole working copy if
> I can." So that user will do 'svn up wc/A/D/G/tau wc', and if
> something dies in the middles of the 'wc' update, at least the
> user has 'tau' up-to-date.
>
> 2. Also, we have this notion of an anchor and a target for updates
> (the anchor is where the update editor is rooted, the target is
> the actual thing we want to update). I needed a function that
> would NOT screw with my input paths so that I could tell the
> difference between someone being in A/D and saying 'svn up G' and
> being in A/D/G and saying 'svn up .' -- believe it or not, these
> two things don't mean the same thing. svn_path_condense_targets
> plays with absolute paths (which is fine, so does
> svn_path_remove_redundancies), but the difference is that it
> actually tweaks those targets to be relative to the "grandfather
> path" common to all the targets. Updates don't require a
> "grandfather path" at all, and even if it did, the whole
> conversion to an absolute path drops the crucial difference
> between saying "i'm in foo, update bar" and "i'm in foo/bar,
> update '.'"
>
> Hope this helps.
>
> By the way, there are likely to be some changes to the way commits
> work that may require similar requirements as the update case. If
> this happens, I will most certainly be trying to merge your function
> and mine together!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:30 2006