Brock Janiczak wrote:
> So far we only support outgoing changesets.
As I understood it is specific for Eclipse 3.2. I wonder what options
do we have in order to see this stuff in official Subversion releases?
> Supporting incoming
> changesets is possible, but it is a considerable amount of work. In
> theory it is simple. Run an svn log command on each file to get the
> latest history then group them by version number.
Hmm, can't you just use incoming revisions? In other words, if sync
view is in incoming mode, then just run svn log on project, get affected
paths for each revision and filter out resources outside of the project.
For first iteration it would make sense to only allow this stuff for
"In", but not for "In and Out" mode in order to not merge with outgoing
changes. So, when changeset option is activated you can use different
> The branch you mentioned was intended only for changeset support. At
> some point we will probably have to create a branch for the 3.2 stuff,
> as changesets are not API compatible between 3.1 and 3.2, which means
> maintaining another version of subclipse. Yay.
> If you are going to be creating patches, it would be easiest to create
> them against the trunk.
> Adding a page to the common history view is fairly trivial. I created a
> history page for Confluence a while ago if you are interested.
Sure. I'd be interested to take a look.
> Team have added new API for versions (FileHistoryProvider, FileHistory
> and IFileRevision), so it is possible they are planning on pushing some
> of the CVS history page down into team (although i haven't seen any bugs
> to confirm this). Also, if we implement this interface we should get
> live annotate for free.
Good point. Though current live annotation is quite limited. :-(
> Eugene Kuleshov wrote:
>> It looks like there is an Eclipse 3.2 branch has been created in
>> Subclipse repository and there is already some work done on active
>> change set support. Is it only for outgoing change sets? How about
>> grouping incoming changes by revisions?
>> I also would like to look at support for common History view
>> introduced in Eclipse 3.2. Is this branch would be the right place to
>> work on such patches?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun May 21 09:23:26 2006