Ian Brockbank wrote:
>> I have itch to get an update action from history view, but
>>it would
>>be really better to implement sync view features like commit sets.
>>Currently I feel blind looking at svn sync view in incoming changes
>>mode, so I have to run svn history for the whole project in
>>order to see
>>what was going on with the project, but it is not quite the same,
>>because I can't run update from history view and it is also show too
>>many changes (sync view in cvs show changes from the head up to local
>>revision).
>
> What is the difference between an Eclipse "CVS commit set" and a
> Subversion revision?
I look at CVS commit set as a logical group of changes which is
belong to some specific activity, change or refactoring.
> My understanding of commit sets is that they are trying to add
> atomic commit-style functionality on top of an RCS that doesn't have any
> concept that changes might affect multiple files.
I don't think that goal was to provide atomic functionality.
More importanly, you see incoming changes sliced along activities.
> Subversion supports this
> out of the box. Given this, I would much rather work with "the changes
> committed by svn in a single revision". But I haven't used Eclipse and
> CVS for a while, so maybe my understanding of commit sets is wrong.
Well, if you just picking up changes, you can either do update or
replace from trunk. I just get used to review incoming changes and this
is very convenient to do in CVS sync view in commit sets mode. You can
see new changes groupped by commit set and sortable by date, user or
comment. You also see "compressed" folders for resources under any given
commit set and have update/rollback/merge actions handy. The same
representation is also awailable when you comparing tags, branches or
dates and when merging branches.
So, it is very different from the history view in functionality and
in representation of the very similar data.
regards,
Eugene
Received on Wed Jun 22 00:16:33 2005