Mark Phippard wrote:
>>> 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?
>> Mark would have to make the call on this one. I tried using fragments
>> and version dependent features, but that required using massive amounts
>> of reflection. It looks like the only option is to branch off a new
>> version (1.2 or something) and keep both branches up to date, but the
>> 3.1 version will be the main focus for development.
>
> If this feature, and possibly the History change, are finished. What I
> would probably do is turn trunk development into 3.2. Then the only
> question is whether it would be worth having a release line specifically
> for 3.1. I think there are a few nice changes in trunk that are not in
> the 1.0.x branch, but I am not sure if they would justify their own
> release. We could possibly create a release specifically for 3.1 and add
> in Outgoing Change Set support based on 3.1. We already have a patch that
> does it.
>
> In either event, we would just backport select features to the 1.0.x and
> possibly 3.1 branch as needed. But these would mostly just be stable,
> bug-fix releases.
I wonder if there is any reason to stay with Eclipse 3.1? I heard
that there will be no Rational RAD product based on Eclipse 3.1...
>>> 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.
>> yep, that appears to work. I do have one question though, as i don't
>> use SVN on a regular basis. When you check in a file, the global
>> version number is incremented and the version and last changed revision
>> is updated on the file. Is the 'current' version of all of the files in
>> the working copy also updated to this new version number, or do you have
>> to svn update them?
>
> When a file is committed, nothing but that file is updated. Not even the
> folder that contains the file. When you run svn update, it will update
> the Revision to whatever you updated to (HEAD). The Last Changed Revision
> lets you know the last time that file was changed.
>
>> If you do have to run the update, how can we know
>> over which revision range we need to run the log command?
>
> Honestly, when I look at this feature in CVS, I still have no idea what it
> does or what it is trying to tell me. So I have no idea what supporting
> it would mean for Subverison. In other words, sorry, I cannot answer.
I am not sure what you mean, but the whole reason is to see commits
grouped by change sets (in case of SVN it will be per revision). So, I
won't have to open history view for project or resource and then scan
trough affected paths like it is now, but instead will be able to see
this information right in the Synchronize view. This would speedup
browsing trough changes and help to review them quicker because I won't
have to wait while history view fetch affected paths when I move to next
revision.
So, the major usecase for this is to review changes before updating.
Current information on Sunchronize view doesn't say much about nature of
changes and you have to open history view per project and then dig into
the affected paths using very small screen area).
One open question is how to apply update when there are several new
revisions available. Lets saye are incoming revisions 200, 195 and 160.
I can think of several options:
1. update per resource in this case and issue some warning when updating
revision 200 and it contains change on resource that had been also
updated in revision 160...
2. revisions 195 and 160 be automatically picked up when call update on
revision 200
3. exclude resources from revisions 195 and 160 if those resources
appears in revision 200
I'd vote for option 1.
regards,
Eugene
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Sun May 21 21:21:55 2006