Home » Eclipse Projects » Eclipse Platform » Buckminster CVS provider
| Buckminster CVS provider [message #285803] |
Thu, 26 May 2005 04:16  |
Eclipse User |
|
|
|
Originally posted by: thhal.mailblocks.com
Hi,
I'm developing the CVS part of Buckminster
http://www.eclipse.org/proposals/eclipse-buckminster. One of the tasks
at hand is to obtain information (tags and sometimes file content) from
remote repositories without checking out. I don't want to invent the
weel again so I started to investigate what's already in the cvs plugin.
As it turns out, everything that could be of use to me is in the
team.internal.ccvs packages.
So my first question is:
Would it be of interest to create a more public interface to the CVS
functionality? I would like a subset of the classes found in packages:
org.eclipse.team.internal.ccvs.core
org.eclipse.team.internal.ccvs.core.client
org.eclipse.team.internal.ccvs.core.connection
org.eclipse.team.internal.ccvs.core.resources
org.eclipse.team.internal.ccvs.core.util.KnownRepositories
Everything in the cvs plugin assumes that the destination for a
check-out is a project in a workspace. Buckminster takes a slightly
different approach in that we divide the checkout into two distinct phases:
a) Retrieve files from the remote repository and place them in a local
directory.
b) Bind those files to a project in the workspace.
The binding phase is flexible since we cannot stipulate that a CVS
module is equal to a project in all cases. The project does not exist
yet during phase a.
My second question is:
How can I use the cvs-plugin to check things out to a location that is
not yet part of a workspace? Would the best approach be to write my own
implementation of the ICVSFolder/ICVSFile stuff? Or should I create a
temporary project and set up Eclipse links?
Kind regards,
Thomas Hallgren
|
|
|
| Re: Buckminster CVS provider [message #285844 is a reply to message #285803] |
Thu, 26 May 2005 13:39  |
| Eclipse User |
|
|
|
Originally posted by: Michael_Valenta.oti.com
Thomas,
"Thomas Hallgren" <thhal@mailblocks.com> wrote in message
news:d740ro$6lr$1@news.eclipse.org...
> Hi,
> I'm developing the CVS part of Buckminster
> http://www.eclipse.org/proposals/eclipse-buckminster. One of the tasks at
> hand is to obtain information (tags and sometimes file content) from
> remote repositories without checking out. I don't want to invent the weel
> again so I started to investigate what's already in the cvs plugin. As it
> turns out, everything that could be of use to me is in the
> team.internal.ccvs packages.
>
> So my first question is:
> Would it be of interest to create a more public interface to the CVS
> functionality? I would like a subset of the classes found in packages:
>
> org.eclipse.team.internal.ccvs.core
> org.eclipse.team.internal.ccvs.core.client
> org.eclipse.team.internal.ccvs.core.connection
> org.eclipse.team.internal.ccvs.core.resources
> org.eclipse.team.internal.ccvs.core.util.KnownRepositories
It is unlikely that the CVS plugin will ever provide a public API that is
CVS specific. The main reason for this is that there are not many commercial
applications that want to be bound specifially to CVS. A much more
interesting prospect is the support for a general Team API such as the one
proposed by JSR 147. At the current time, this API is not finalized and
there are no repository tools that implement it. However, this may change in
the future, at which point, a CVS implementation of this API may be
considered.
With that in mind, you may want to reconsider how you intend to interact
with repository providers. There are many tools that use the internal
packages of CVS with the understanding that they may be broken accross
releases and you can do this same thing. However, you would be binding your
tool to CVS and may not be able to get the same API from other repository
tooling. I think you should avoid using the CVS plugin directly at all costs
(unless you never intend on supporting anything but CVS and don't care about
being broken accross releases). You could argue that you are only doing this
as part of the exploritory part of your project in order to determine what
is possible. That is fine, but you should be aware that not all repository
tools have the same behavior as CVS or the same level of integration into
Eclipse. Although you may be able to define a repository agnostic API that
meets your needs, you may still end up tied to CVS due to the inability or
unwillingness of other repository tools to implement the required API.
> Everything in the cvs plugin assumes that the destination for a check-out
> is a project in a workspace. Buckminster takes a slightly different
> approach in that we divide the checkout into two distinct phases:
>
> a) Retrieve files from the remote repository and place them in a local
> directory.
> b) Bind those files to a project in the workspace.
>
> The binding phase is flexible since we cannot stipulate that a CVS module
> is equal to a project in all cases. The project does not exist yet during
> phase a.
>
> My second question is:
> How can I use the cvs-plugin to check things out to a location that is not
> yet part of a workspace? Would the best approach be to write my own
> implementation of the ICVSFolder/ICVSFile stuff? Or should I create a
> temporary project and set up Eclipse links?
Yes, I suspect you could provide your own ICVSResource implementations and
checking out into a temporary project would also work. However, I would say
that there is a good possibility that neither of these is the best approach
for the following reason. The current architecture in Eclipse uses the
workspace as the "API" between repository tooling and other tools (e.g.
JDT). In other words, the repository tooling provides user initiated
commands that act on projects in the workspace. By adding an layer of
indirection between the repository tooling and the project, you are breaking
this API (i.e. repository context menu operations would not appear on this
"bound" project). The projects that you create will require additional API
from repository tooling.
Most repository tools offer some means of configuring the local workspace.
For instance CVS has the CVSROOT/modules file for configuring local projects
that have a directory structure that doesn't match that of the server. Other
tools have different mechanisms for this. It may be worthwhile to look into
whether these mechanisms will meet your needs. Another idea may be to define
a means of specifying the mapping from the repository to the local
workspace. Repository providers could then use this to configure the
checkout (although, as I said before, it may be that some repostory tools
may not be capable of providing this functionality). This would be similar
to the idea of project sets but would be more comprehensive.
> Kind regards,
> Thomas Hallgren
Michael
|
|
|
| Re: Buckminster CVS provider [message #285859 is a reply to message #285844] |
Thu, 26 May 2005 17:52 |
| Eclipse User |
|
|
|
Originally posted by: thhal.mailblocks.com
Michael,
Thanks for your long reply. Buckminster will indeed interact with a lot
of different source code control systems. We plan to provide integration
for CVS, SVN, and Perforce already in our first milestone. Buckminster
also interacts with other types of systems from which artifacts can be
retrieved such as URL based repositories.
Buckminster have an abstraction prototype in place for all interaction
with such systems and new implementations can be added using a couple of
extension points. As everyday users of the mentioned source code control
systems and as chastened ClearCase users, we are well aware of how
different those systems are. We aim to provide a very flexible and
configurable abstraction.
The questions I asked in my previous posting where related to our CVS
implementation of this abstraction. I think my best course of action is
to do what you say many other tools do, and use the internal interfaces
directly. At least for now.
If there is ongoing work to create a provider agnostic Team API, I'd be
very interested in looking at it. Perhaps some of our efforts and ideas
could be merged?
Regards,
Thomas Hallgren
Michael Valenta wrote:
> Thomas,
>
> "Thomas Hallgren" <thhal@mailblocks.com> wrote in message
> news:d740ro$6lr$1@news.eclipse.org...
>
>>Hi,
>>I'm developing the CVS part of Buckminster
>>http://www.eclipse.org/proposals/eclipse-buckminster. One of the tasks at
>>hand is to obtain information (tags and sometimes file content) from
>>remote repositories without checking out. I don't want to invent the weel
>>again so I started to investigate what's already in the cvs plugin. As it
>>turns out, everything that could be of use to me is in the
>>team.internal.ccvs packages.
>>
>>So my first question is:
>>Would it be of interest to create a more public interface to the CVS
>>functionality? I would like a subset of the classes found in packages:
>>
>>org.eclipse.team.internal.ccvs.core
>>org.eclipse.team.internal.ccvs.core.client
>>org.eclipse.team.internal.ccvs.core.connection
>>org.eclipse.team.internal.ccvs.core.resources
>>org.eclipse.team.internal.ccvs.core.util.KnownRepositories
>
>
> It is unlikely that the CVS plugin will ever provide a public API that is
> CVS specific. The main reason for this is that there are not many commercial
> applications that want to be bound specifially to CVS. A much more
> interesting prospect is the support for a general Team API such as the one
> proposed by JSR 147. At the current time, this API is not finalized and
> there are no repository tools that implement it. However, this may change in
> the future, at which point, a CVS implementation of this API may be
> considered.
>
> With that in mind, you may want to reconsider how you intend to interact
> with repository providers. There are many tools that use the internal
> packages of CVS with the understanding that they may be broken accross
> releases and you can do this same thing. However, you would be binding your
> tool to CVS and may not be able to get the same API from other repository
> tooling. I think you should avoid using the CVS plugin directly at all costs
> (unless you never intend on supporting anything but CVS and don't care about
> being broken accross releases). You could argue that you are only doing this
> as part of the exploritory part of your project in order to determine what
> is possible. That is fine, but you should be aware that not all repository
> tools have the same behavior as CVS or the same level of integration into
> Eclipse. Although you may be able to define a repository agnostic API that
> meets your needs, you may still end up tied to CVS due to the inability or
> unwillingness of other repository tools to implement the required API.
>
>
>>Everything in the cvs plugin assumes that the destination for a check-out
>>is a project in a workspace. Buckminster takes a slightly different
>>approach in that we divide the checkout into two distinct phases:
>>
>>a) Retrieve files from the remote repository and place them in a local
>>directory.
>>b) Bind those files to a project in the workspace.
>>
>>The binding phase is flexible since we cannot stipulate that a CVS module
>>is equal to a project in all cases. The project does not exist yet during
>>phase a.
>>
>>My second question is:
>>How can I use the cvs-plugin to check things out to a location that is not
>>yet part of a workspace? Would the best approach be to write my own
>>implementation of the ICVSFolder/ICVSFile stuff? Or should I create a
>>temporary project and set up Eclipse links?
>
>
> Yes, I suspect you could provide your own ICVSResource implementations and
> checking out into a temporary project would also work. However, I would say
> that there is a good possibility that neither of these is the best approach
> for the following reason. The current architecture in Eclipse uses the
> workspace as the "API" between repository tooling and other tools (e.g.
> JDT). In other words, the repository tooling provides user initiated
> commands that act on projects in the workspace. By adding an layer of
> indirection between the repository tooling and the project, you are breaking
> this API (i.e. repository context menu operations would not appear on this
> "bound" project). The projects that you create will require additional API
> from repository tooling.
>
> Most repository tools offer some means of configuring the local workspace.
> For instance CVS has the CVSROOT/modules file for configuring local projects
> that have a directory structure that doesn't match that of the server. Other
> tools have different mechanisms for this. It may be worthwhile to look into
> whether these mechanisms will meet your needs. Another idea may be to define
> a means of specifying the mapping from the repository to the local
> workspace. Repository providers could then use this to configure the
> checkout (although, as I said before, it may be that some repostory tools
> may not be capable of providing this functionality). This would be similar
> to the idea of project sets but would be more comprehensive.
>
>
>>Kind regards,
>>Thomas Hallgren
>
>
> Michael
>
>
|
|
|
| Re: Buckminster CVS provider [message #285886 is a reply to message #285859] |
Fri, 27 May 2005 09:45 |
| Eclipse User |
|
|
|
Originally posted by: Michael_Valenta.oti.com
Thomas,
There is currently no work being done on a general Eclipse Team API per say
although new API is introduced as needed (for example, the
logical-to-physical support planned for 3.2 will require some supporting
repository tooling API). I believe that this is a task that must be driven
by the repository tools and their clients. It sounds like Buckminster is
such a client and it sounds like you are defining the piece of API that your
component will require. I think this is the right approach.
My main concern involves the Team architecture in Eclipse. Currently,
repository providers are bound at the project level and it sounds like
Buckminster requires binding at sub-project levels (i.e. sub-folders). I'm
not saying that the architecture couldn't be changed to accomodate new
requirements. However, any changes would need to be made in a 100% backwards
compatible fashion and will, of course, require the support of the Eclipse
Platform PMC. You may already be aware of this but I thought it was worth
mentioning anyway.
Another concern I have is that the funtionality Buckminster is proposing to
provide may overlap with the funtionality provided by repository tooling.
It's not a big deal with CVS since there is little or no overlap. However,
there may be complications with more sophisticated tools such as ClearCase
as they compete with Buckminster for control of the project configuration.
However, it sounds like you have more knowledge of this area than I do so
I'll leave it at that.
Cheers,
Michael
"Thomas Hallgren" <thhal@mailblocks.com> wrote in message
news:42964514.1090902@mailblocks.com...
> Michael,
> Thanks for your long reply. Buckminster will indeed interact with a lot of
> different source code control systems. We plan to provide integration for
> CVS, SVN, and Perforce already in our first milestone. Buckminster also
> interacts with other types of systems from which artifacts can be
> retrieved such as URL based repositories.
>
> Buckminster have an abstraction prototype in place for all interaction
> with such systems and new implementations can be added using a couple of
> extension points. As everyday users of the mentioned source code control
> systems and as chastened ClearCase users, we are well aware of how
> different those systems are. We aim to provide a very flexible and
> configurable abstraction.
>
> The questions I asked in my previous posting where related to our CVS
> implementation of this abstraction. I think my best course of action is to
> do what you say many other tools do, and use the internal interfaces
> directly. At least for now.
>
> If there is ongoing work to create a provider agnostic Team API, I'd be
> very interested in looking at it. Perhaps some of our efforts and ideas
> could be merged?
>
> Regards,
> Thomas Hallgren
>
>
> Michael Valenta wrote:
>> Thomas,
>>
>> "Thomas Hallgren" <thhal@mailblocks.com> wrote in message
>> news:d740ro$6lr$1@news.eclipse.org...
>>
>>>Hi,
>>>I'm developing the CVS part of Buckminster
>>>http://www.eclipse.org/proposals/eclipse-buckminster. One of the tasks at
>>>hand is to obtain information (tags and sometimes file content) from
>>>remote repositories without checking out. I don't want to invent the weel
>>>again so I started to investigate what's already in the cvs plugin. As it
>>>turns out, everything that could be of use to me is in the
>>>team.internal.ccvs packages.
>>>
>>>So my first question is:
>>>Would it be of interest to create a more public interface to the CVS
>>>functionality? I would like a subset of the classes found in packages:
>>>
>>>org.eclipse.team.internal.ccvs.core
>>>org.eclipse.team.internal.ccvs.core.client
>>>org.eclipse.team.internal.ccvs.core.connection
>>>org.eclipse.team.internal.ccvs.core.resources
>>>org.eclipse.team.internal.ccvs.core.util.KnownRepositories
>>
>>
>> It is unlikely that the CVS plugin will ever provide a public API that is
>> CVS specific. The main reason for this is that there are not many
>> commercial applications that want to be bound specifially to CVS. A much
>> more interesting prospect is the support for a general Team API such as
>> the one proposed by JSR 147. At the current time, this API is not
>> finalized and there are no repository tools that implement it. However,
>> this may change in the future, at which point, a CVS implementation of
>> this API may be considered.
>>
>> With that in mind, you may want to reconsider how you intend to interact
>> with repository providers. There are many tools that use the internal
>> packages of CVS with the understanding that they may be broken accross
>> releases and you can do this same thing. However, you would be binding
>> your tool to CVS and may not be able to get the same API from other
>> repository tooling. I think you should avoid using the CVS plugin
>> directly at all costs (unless you never intend on supporting anything but
>> CVS and don't care about being broken accross releases). You could argue
>> that you are only doing this as part of the exploritory part of your
>> project in order to determine what is possible. That is fine, but you
>> should be aware that not all repository tools have the same behavior as
>> CVS or the same level of integration into Eclipse. Although you may be
>> able to define a repository agnostic API that meets your needs, you may
>> still end up tied to CVS due to the inability or unwillingness of other
>> repository tools to implement the required API.
>>
>>
>>>Everything in the cvs plugin assumes that the destination for a check-out
>>>is a project in a workspace. Buckminster takes a slightly different
>>>approach in that we divide the checkout into two distinct phases:
>>>
>>>a) Retrieve files from the remote repository and place them in a local
>>>directory.
>>>b) Bind those files to a project in the workspace.
>>>
>>>The binding phase is flexible since we cannot stipulate that a CVS module
>>>is equal to a project in all cases. The project does not exist yet during
>>>phase a.
>>>
>>>My second question is:
>>>How can I use the cvs-plugin to check things out to a location that is
>>>not yet part of a workspace? Would the best approach be to write my own
>>>implementation of the ICVSFolder/ICVSFile stuff? Or should I create a
>>>temporary project and set up Eclipse links?
>>
>>
>> Yes, I suspect you could provide your own ICVSResource implementations
>> and checking out into a temporary project would also work. However, I
>> would say that there is a good possibility that neither of these is the
>> best approach for the following reason. The current architecture in
>> Eclipse uses the workspace as the "API" between repository tooling and
>> other tools (e.g. JDT). In other words, the repository tooling provides
>> user initiated commands that act on projects in the workspace. By adding
>> an layer of indirection between the repository tooling and the project,
>> you are breaking this API (i.e. repository context menu operations would
>> not appear on this "bound" project). The projects that you create will
>> require additional API from repository tooling.
>>
>> Most repository tools offer some means of configuring the local
>> workspace. For instance CVS has the CVSROOT/modules file for configuring
>> local projects that have a directory structure that doesn't match that of
>> the server. Other tools have different mechanisms for this. It may be
>> worthwhile to look into whether these mechanisms will meet your needs.
>> Another idea may be to define a means of specifying the mapping from the
>> repository to the local workspace. Repository providers could then use
>> this to configure the checkout (although, as I said before, it may be
>> that some repostory tools may not be capable of providing this
>> functionality). This would be similar to the idea of project sets but
>> would be more comprehensive.
>>
>>
>>>Kind regards,
>>>Thomas Hallgren
>>
>>
>> Michael
|
|
|
| Re: Buckminster CVS provider [message #285909 is a reply to message #285803] |
Fri, 27 May 2005 14:36 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
It looks like your question got answered. I'd just like to add how nice
it would be to be able to not (necessarily) bind check-outs to projects.
Since Eclipse projects stick files into the project folder that are
Eclipse-specific, they are not appropriate for multi-tool development shops.
Even worse, Eclipse project files are version-specific. Plug-in writers
who move their development forward to the latest Eclipse release often
find they can no longer go backward. If you can't build on earlier
Eclipse versions, you can't readily debug problems that are reported
against earlier versions.
Bob Foster
Thomas Hallgren wrote:
> Hi,
> I'm developing the CVS part of Buckminster
> http://www.eclipse.org/proposals/eclipse-buckminster. One of the tasks
> at hand is to obtain information (tags and sometimes file content) from
> remote repositories without checking out. I don't want to invent the
> weel again so I started to investigate what's already in the cvs plugin.
> As it turns out, everything that could be of use to me is in the
> team.internal.ccvs packages.
>
> So my first question is:
> Would it be of interest to create a more public interface to the CVS
> functionality? I would like a subset of the classes found in packages:
>
> org.eclipse.team.internal.ccvs.core
> org.eclipse.team.internal.ccvs.core.client
> org.eclipse.team.internal.ccvs.core.connection
> org.eclipse.team.internal.ccvs.core.resources
> org.eclipse.team.internal.ccvs.core.util.KnownRepositories
>
>
> Everything in the cvs plugin assumes that the destination for a
> check-out is a project in a workspace. Buckminster takes a slightly
> different approach in that we divide the checkout into two distinct phases:
>
> a) Retrieve files from the remote repository and place them in a local
> directory.
> b) Bind those files to a project in the workspace.
>
> The binding phase is flexible since we cannot stipulate that a CVS
> module is equal to a project in all cases. The project does not exist
> yet during phase a.
>
> My second question is:
> How can I use the cvs-plugin to check things out to a location that is
> not yet part of a workspace? Would the best approach be to write my own
> implementation of the ICVSFolder/ICVSFile stuff? Or should I create a
> temporary project and set up Eclipse links?
>
> Kind regards,
> Thomas Hallgren
|
|
|
Goto Forum:
Current Time: Fri Jun 06 21:57:24 EDT 2025
Powered by FUDForum. Page generated in 0.03842 seconds |
Home