Write-back to repositories? [message #1053139] |
Thu, 02 May 2013 15:56 |
Eclipse User |
|
|
|
Has there been any discussion about enabling buckminster to write-back into mutable repositories?
One nice thing around the materialization concept is that the one who is triggering a materialization does not need to know where the components actually come from. Actually this might change over time. This seems to be different when submitting component changes. There, an Eclipse user need to deal with the specific repository by, for instance, looking at a Perforce changelist and submitting artifacts. Besides the loss of abstraction this may lead to situations where changes of one component get submitted whereas changes of dependent components are not.
Maybe this not very relevant in reality (otherwise this feature would have been there)? My context is that I want to address "causal" developers which should not be exposed to technical details. They should be able to materialize everything for a certain project, work on it, and basically submit everything back as a whole.
Regards,
Klaus
|
|
|
Re: Write-back to repositories? [message #1053277 is a reply to message #1053139] |
Fri, 03 May 2013 13:52 |
Henrik Lindberg Messages: 2509 Registered: July 2009 |
Senior Member |
|
|
On 2013-02-05 17:56, Klaus Kopecz wrote:
> Has there been any discussion about enabling buckminster to write-back
> into mutable repositories? One nice thing around the materialization
> concept is that the one who is triggering a materialization does not
> need to know where the components actually come from. Actually this
> might change over time. This seems to be different when submitting
> component changes. There, an Eclipse user need to deal with the specific
> repository by, for instance, looking at a Perforce changelist and
> submitting artifacts. Besides the loss of abstraction this may lead to
> situations where changes of one component get submitted whereas changes
> of dependent components are not.
> Maybe this not very relevant in reality (otherwise this feature would
> have been there)? My context is that I want to address "causal"
> developers which should not be exposed to technical details. They should
> be able to materialize everything for a certain project, work on it, and
> basically submit everything back as a whole.
> Regards,
> Klaus
afaik, the only concrete discussions have been to enable
comitting/pushing changes produced by a build process, not to aid a user
in some sort of über commit.
Don't know what other tools offer in this area; Mylyn comes to mind as a
possible tool as it keeps track of things that have changed.
At one point we were discussing a sort of smart Buckminster co-pilot
that observed everything going on in the workspace, keeping track of
where things came from and suggesting appropriate actions to the user;
"you are using these jars that you added from an unknown source, do you
want to manage them with Buckminster?" The sort of thing you are
suggesting sort of falls in this category. We concluded that there was
simply too much work to create the co-pilot (we referred to it as
"active workspace management"). It quickly became quite complex.
Regards
- henrik
|
|
|
Powered by
FUDForum. Page generated in 0.03388 seconds