Re: [platform-team-dev] RE: what are the Platform plans for Team/FTP?

[Denny Valliant <valliant@xxxxxxx>]

Michael Valenta wrote:
>
> Mik,
>
> Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=146917 is a request
> for a unified Synchronize view.

Comment #8 seems to make sense to me (UI wise).  It does sorta look like
everything we need is already in place, for the most part.
At least the framework around which to build. ;-)

I'd opt for the context menu approach vs. a bunch of buttons on the sync
view toolbar (if that was the suggested solution/problem prior to #8).

I'll admit, I have very little experience with the actual facets of Team
API... I've done a little work on Subclipse, and so I also checked out
the CVS plugin, and then I did a little work on a SFTP plugin, which I
had hoped to use the Team API and sync view with eventually (but jcraft
has a swell SFTP plugin that utilizes the Team API (at least the sync
view;) so I haven't been too motivated to continue that work on the
other SFTP plugin).

Personally, I don't mind having to switch the type of synchronization in
the sync view, or the provider having to supply custom context items for
selected resources (SFTP > Commit || SVN > Commit || CVS > Commit,
depending on what Team Providers the resource is synced with?).
A unified sync view would be cool, but would need a different UI (IMHO;
which isn't worth much, mind), or at least tweaks to the UI. Extra
column maybe in the sync view?  That's really besides my point though.

What I would like to see is a common place for Team Providers to "plug
in" to Eclipse.  I know that's the whole goal of the Team API, I just
wanted to be sure that the multi-provider per project idea is incorporated.

We don't need to force providers to use the API, but it would be awesome
to have the ability to tie in a little better, without having to recode
so much for each provider to integrate with Eclipse (which is already
getting better (fer instance diffs and changesets, yay!), good work folks!).

Change sets are awesome, but I don't know how they would be implemented
for something like SFTP, which is for sure Team, but only a "single
revision" repository of sorts, with no real "meta data" (built into it).

Like I said, all I'm doing currently is using SFTP/FTP and SVN on the
same projects (which I really like).  I would dislike having to
disconnect from one provider and reconnect to another simply to sync my
project with two (or more) providers (my main motivation for posting).

For all I know, things are already going the way I'm proposing. I just
wanted to "make some noise" in case Team API in general was leaning
toward a more singular approach.

I'm a perpetual, rather unfocused newbie, so if my comments are naive or
not well researched/thought out or whatever, my apologies.  I just
dabble with this stuff. :-/ I haven't done anything with Deltas or
anything along those lines; just basic key-binding and other "easy"
things (FWIW).
Sorry if my input is less than concise regarding Team API et al.

Mik, if you've got ideas on how to implement change sets for SFTP and
the like, I'd be interested to at least talk about it, although I can't
contribute any real technical expertise, and haven't even peeked at how
Team API is working with them.
Could be we're already "faking" them anyway, (royal we ;) so making them
work for SFTP might not be as hard as I was initially thinking.
(by "faking" I mean tracking them within Eclipse vs. extending the
provider itself, if that makes sense and is properly termed =])

Long winded, am I. Wow. Sorry for the thoughts in bulk, folks.

And a big thanks to all who make this great stuff possible.
-Denny
--
"Yeah, they never show that part on TV."
-Brock Samson

> *"Mik Kersten" 
> 
> +1  I've been using and liking the Synchronize view for file transfers via
> FTP
> 
> In terms of further integrating it, it would be helpful to have Change Sets
> work for it.  Also, I rely so heavily on the Synchronize view always showing
> me the diff between my workspace and the rest of the world that I find it
> confusing to have no way of knowing that there are changes in a SVN or FTP
> synchronization when I've got my CVS synchronization up (most of the time).
> So I'm wondering if anyone has considered or requested having all
> synchronizations show?  E.g. via an All Synchronizations menu that appears
> similarly to All Models.  Being able to set one schedule for all of them
> would be convenient too.
> 
> Mik
> 
> 
>> -----Original Message-----
>> From: platform-team-dev-bounces@xxxxxxxxxxx [mailto:platform-team-dev-
>> bounces@xxxxxxxxxxx] On Behalf Of Denny Valliant
>> Sent: Tuesday, September 12, 2006 10:55 PM
>> To: Generic team support framework
>> Subject: [platform-team-dev] RE: what are the Platform plans for Team/FTP?
>>
>> I really like the synchronize view for file transfer.
>>
>> I /especially/ like how I can currently have one project "synchronized"
>> with both a Subversion repository AND a remote server via SFTP/FTP.
>>
>> I just wanted to share how deeply grateful I am to be able to do this,
>> and would like the powers that be to know that I really hope not to lose
>> this ability as the Team API progresses/evolves.
>>
>> And I really like the synchronize mentality vs. "mapped drive"
>> mentality.  But I said that already. =]
>>
>> The Team API is getting sweet.                 Thanks.
>> -Denny
>>
>> Michael Valenta wrote:
>> > 3) The Team/Extras feature uses the synchronization framework to do file
>> > transfers. Originally, this was done as a proof on concept to show that
>> > the synchronization framework was applicable to more than just
>> > repository synchronization. I would be curious to know from those that
>> > have used it what they think of the approach. If the general concensus
>> > was that this was the way to go, then we could investigate how to
>> > improve the support over top of EFS. However, if it was generally felt
>> > that an alternate approach to doing file transfers was preferable, we
>> > could work towards that.
>> >
>> > If anyone has any comments, thoughts or ideas about this, feel free to
>> > share them.
>> > Michael