Understand 1. Still unclear on 2. (Probably lack of sleep, I have been
a little busy lately). Feel free to add the docstring to the code for
now. Maybe once I grok what you are doing I will modify it somehow.
Didn't mean to be terse before, just so you know, it was simply a matter
of wondering.
On Wed, May 16, 2001 at 02:59:49PM -0500, cmpilato@collab.net wrote:
> 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!
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:30 2006