Barry Scott wrote:
> I'm writing a GUI that any one should be able to use on any SVN project.
> I cannot know what conventions are in force. All I can do is call the
> SVN API and query it for information. SVN has no notion of a "tag",
> "branch" or "label".
You mean that SVN [currently] has no API to retrieve tag/branch information from
a specific file (apart from retrieving the log). You're right; Subversion is
a repository-centric, as opposed to a file-centric SCM program. That means that
it is easy to retrieve a collection of files from a specific revision (tag), but
it is hard to locate all instances (copies) of a given file in the repository.
> In my mind a "label" is a symbolic name to an interesting event in an
> items history. How do I find theses events?
Currently, only by parsing the log entries.
> Given I start with a user requesting the history of an item in their
> working copy how do I find the "tags" directory and the "branches"
> directory? Are there one or many of these?
That's not how Subversion operates [currently], so you can only hit the logs.
> No its not my project, I'm writing a tool for others to use and I'm not
> forcing any conventions on them.
But you are forcing the convention of a file-centric SCM onto a
repository-centric SCM. By doing so, you are always going to be struggling
against the basic design choices which went into Subversion. At some time in
the future (2.0?), I think it is likely that there will be an API which will
retrieve the information you desire server-side. You aren't the only who is
having this problem.
> I'm in England and my pysvn repo is in Chicago, I can assure you that access is
> slow at 4 seconds per svn log and around 3 seconds per svn ls.
But I was specifically discussing the speed of URL-to-URL diffs (which are
server-side processed), so your bandwidth should not be an issue. You are
talking about transferring [relatively] large quantities of data (log entries or
large directory listings) over the wire, where your bandwidth _is_ the limiting
factor. Your basic problem is that currently you are working against
Subversion, rather than with it; as I said above, you just don't have any better
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Apr 4 19:24:34 2004