[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] git mv, duplicated projects and graduating projects out of incubation/ (was Re: build of deleted files/classes)
- From: Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>
- Date: Fri, 28 Jan 2011 22:16:25 +0100
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7
On 01/28/2011 07:46 PM, Scott Lewis wrote:
> On 1/28/2011 10:00 AM, Markus Alexander Kuppe wrote:
>> On 01/28/2011 06:35 PM, Scott Lewis wrote:
>>> Truly...this can't be done? Isn't there a way in Buckminster+git to
>>> materialize only from some modules/parts of a git repository? This
>>> seems strange to me that such restrictions can't be done.
>> There is no such restriction in Buckminster.
> I don't understand...are you saying that restricting the materialization
> to only consider projects that are *not* in <ecf git repo
> base>/incubation is not possible with Buckminster? Or it's possible
> with Buckminster's materialization rules, but because the SCM structure
> has been hidden from Buckminster (next para)...that Buckminster doesn't
> have the necessary info?
It's the latter.
>> It's rather the way the
>> ECF's SCM<> Buckminster integration has been set up. The intention is,
>> that the SCM structure is hidden from Buckminster. This means that the
>> Buckminster metadata does not have to change whenever something is
>> moved/deleted/added in the SCM.
> Markus and all...look...like most/all other things that remain
> incomplete/undone with ECF, I know that all of this is probably
> ultimately a matter of insufficient resources (i.e. your and my
> time)...but if it's technically possible, I do think having flexibility
> to exclude parts of a repo would be useful for this use case
> (incubation) and perhaps others.
> As all can probably tell, I've been forced to waste a couple of days
> worth time (mine, Markus', others) already...diagnosing and dealing with
> this...time that could have been spent testing, documenting, and/or
> dealing with other contributions (xml-rpc, etc), or otherwise working
> toward the ECF 3.5 release.
Agreed, it's annoying that the build does not always work out of the
box. But in this case it's not the problem of the build, but rather that
there are suddenly projects with identical names in the repo.
>> What I would suggest is to:
>> 1) diff osgi/bundles/
>> org.eclipse.ecf.osgi.services.remoteserviceadmin and
> How would this be done? (i.e. create a patch is I guess what you are
> suggesting). Command line git client?
Or just regular patch/diff cmd line tools. Maybe even Eclipse' folder
>> 2) remove osgi/bundles/
>> org.eclipse.ecf.osgi.services.remoteserviceadmin (git rm)
>> 3) move
>> incubation/bundles/org.eclipse.ecf.osgi.services.remoteserviceadmin to
> Will this (step 3) even work?...given that after 2 the repo will still
> have info about
> osgi/bundles/org.eclipse.ecf.osgi.services.remoteserviceadmin ?
Without having verified this, I'm pretty sure git can handle this.
>> osgi/bundles/ (git mv)
>> 4) Apply patch created in step 1
> I'm going to either need someone's help/assistance with this...i.e.
> someone that's more comfortable with the git operations above than I
> am...or it's going to take me a while. As you might deduce, I don't
> have time for the necessary education of the subtleties of various git
> operations...e.g. diff, rm, mv...and of course there will likely be
> subtleties that use up time. So...any volunteers? (that are familiar
> with any/all of these operations?)
> Lacking volunteers, I'm more inclined to simply delete the src and
> project files from
> while leaving the directory intact. Objections to that? The incubation
> history doesn't really matter...and won't it still be present anyway
> even if this is what's done?
If it can wait, I will do a proper move tomorrow.