On Tue, 30 Jan 2007, Mark Phippard wrote:
> Dan wrote:
> >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.
I see. So, ideally the changelists themselves would be sotred in the
WC, and any additional information used by Subclipse would piggy-back
off the changelist names in separate storage.
> 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.
Yeah, I noticed that in the bottom pane here:
http://subclipse.tigris.org/images/sync-ss.png
That's just like a foreign-key relationship in a RDBMS; it'll work fine.
- application/pgp-signature attachment: stored
Received on Wed Jan 31 01:38:36 2007
