On Thu, 25 Jan 2007, Mark Phippard wrote:
> On 1/25/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
> >
> >Mark Phippard wrote:
> >> On 1/25/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
...
> >>> The only other changelist API is svn_client_[retrieve]_changelist(), which
> >>> we could add support for as well. (To remove a file from a changelist,
> >>> just set the changelist name to "".) Set the changelist is a little
> >>> bit easier than retrieving it, and I wanted to make sure I remembered to
> >>> add everything that JavaHL needs, hence the reason for this patch.
> >>
> >> If we realistically wanted to use this API in Subclipse we would likely
> >> need to maintain our "own database" of what files are in what
> >> changeset. This
> >> would defeat the point of using the API, as that would mean we would not
> >> know about things that other clients did with the same WC.
> >>
> >> Realistically, we would probably need an API to list what files are in
> >> what
> >> changesets. Maybe that would be a new usage of the status API or new
> >> data
> >> available in the current one? I think that is how the CLI is doing it.
Would this make it possible to tie Eclipse's Change Set view into
Subversion's changelist API (that you mention in "Message-ID:
<ff892c5d0701170842i3454a39bye1f0f45f2b8a2e18@mail.gmail.com>"), such
that the glue by which Subclipse "drive[s] the view" can also drive
Subversion's changelist API?
This way, Subclipse could maintain its own database of changelists (if
necessary), but also interact in the same WC with other Subversion
clients.
> >svn_client_set_changelist() takes a changelist name and returns an array
> >of paths which belong to that changelist. I don't think there is an API
> >which lists which changelist a file belongs to, nor one which lists all
> >the changelists which are currently in the WC. Maybe sussman can
> >comment on the feasibility of adding such.
...
> svn status essentially outputs that info. So maybe the ISVNStatus class
> should have a changelist field added to it and the approriate changes made
> to the status API to populate it?
Yes, it this field should be available.
> We already run status to populate the UI where we would show changelists, so
> we might be able to drive it from that.
Sounds like the way to go given the current changelist API.
- application/pgp-signature attachment: stored
Received on Wed Jan 31 00:49:36 2007