Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> What does this function offer that svn_path_condense doesn't, except for
> preserving order? Why does order need to be preserved? Maybe
> svn_path_condense_targets should be modified instead?
Dammit, the very fact that you ask this reminds me that I forgot to
write up the explanation.
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
Received on Sat Oct 21 14:36:30 2006