On 1/30/07, Daniel Rall <dlr@collab.net> wrote:
>
> 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.
Sort of hard to say. It would be very easy today to just relay the
add/delete file to changelist code that we have in place through the SVN
API. In other words, still use our own mechanism to track the changelist,
but also use SVN API so that WC contains same info. The problem would be if
we did not rely on SVN to also tell us the changelists and what is in them,
then we would not be aware of changes to the changelists done outside of
Eclipse. So realistically, I think we would want an all or nothing approach
and without trying it, it is hard to say whether it would work well or not.
One minor issue is that the Eclipse changeset support allows you to store a
commit message so you can work on it in advance of committing. So, at a
minimum, we would need to store that within Eclipse and just associate it
with the changelist name.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on Wed Jan 31 01:21:28 2007