On Wed, May 16, 2001 at 02:59:49PM -0500, email@example.com wrote:
> 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 '.'"
I am guessing that the difference has to do with whether or not we make
a change to the parent entries file? We shouldn't have to anyway should
we? I thought that the entry in the parent dir just contained the name,
and all the info was in the THIS_DIR entry within the child dir.
If we do, what do we do in the case of 'svn update foo/bar
../../baz' What do we take as the place the editor is rooted for the
> 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!
Okay, sounds good.
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
Received on Sat Oct 21 14:36:30 2006
- application/pgp-signature attachment: stored