[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: feature request: replace with -> base revision

From: Eugene Kuleshov <ekuleshov_at_gmail.com>
Date: 2005-08-05 20:34:12 CEST

On 8/5/05, Mark Phippard <MarkP@softlanding.com> wrote:
> Eugene Kuleshov <ekuleshov@gmail.com> wrote on 08/05/2005 01:58:01 PM:
> > Mark, please don't take this personal. It is definetely just my own
> > experience being the nearly the only person (out of other 70 developers
> on the
> > same project) who is actively using Sync view features in Eclipse and
> the only
> > person who can observe in real time what is going on around and only
> person
> > whi see amount of duplicated code and other nonsenses committed each
> day. I
> > gues it give me sort of excuse to beg for similar functionality in
> Subclipse. :-)
> I am not taking it personally, I am saying to be more explicit in
> indicating that this is your opinion only. You often word stuff in
> absolute terms as if there can be no other point of view.

Sorry. Didn't mean to be absolute. Perhaps it is just because English is not
my first language.

You have 70
> developers and only one uses the Synch view, that doesn't tell you
> anything?

Yes it does. I do believe that it was bad idea to put Sync view into
separate perspective by default. It must be on Java perspective. :-)
So, it is basically matter of education... Again, nothing personal.

I have used Eclipse since pre-1.0 and used the CVS client up
> until about 15 months ago when I switched to Subversion. I initially sort
> of likes the Synch view because I was new to CVS, but long before Eclipse
> 3.x came out I had pretty much stopped using it. This could just be
> because I work on smaller projects than you where I do not have any
> trouble keeping up with what is going on just via commit emails.

Actually Sync view improved a lot around 3.0Msomething. So, it wasn't that
nice and didn't have scheduled updates that are most handy. I just get used
to keep up with integration build and early aqusition of new features, so it
may not match others experience to deal with only stable versions.
Also I have about 50 projects in my Eclipse workspace, some of them local
and others comes from open source repositories (including Eclipse and
Subclipse ones). So, it is tricky to stay up to date in such conditions and
I found that email notification doesn't give good aggregation. Again, this
is only my personal experience.

> Righ, each VCS tool has its own things. Honestly I hadrly see that
> Subclipse
> > is much special about branching as you put it, and you and me perhaps on
> > opposite sides of the fence.
> I think my point was more about Subversion vs. CVS than the two Eclipse
> clients. I just find branching and related concepts so simple in
> Subversion that the feature is easy to use for me.

Hmm. My experience with CVS branching was quite ok. Probably because I've
never used WinCVS. :-)

> Anyway, that would be way less important
> > comparing to the Sync view features... :-)
> The specific features you have mentioned that I was indicating that I
> would not expect to ever see are these:
> o commit sets

This is an important one and it should be simplier to implement comparing to
CVS plugin. Or at least I hope so.

o using synch in any way related to branching/merging

Actually more in comparing. Especially when "commit sets" is used. So, you
no need "directory" comparison in editor because Sync view gives that.

o apparently you also see a combination of the previous two

Yes. For comparison between branches/tags. It is actually allows to get
better logical slicing for the flow of changes.

Again, not that I am against them being added, I just do not see it
> meshing with the way the Subversion libraries work and therefore not
> possible to implement.

 I know, I know. But maybe if I'll try to ask loudly but nice, things would
change... eventually. :-)

Received on Sat Aug 6 04:34:12 2005

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.