Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Git/Gerrit Proposal

On 9 June 2010 16:20, Andrew Gvozdev <> wrote:
> +1. Great if this will facilitate the move. However, already a bit familiar
> with git, personally I won't use the test server working on CDT as it will
> just add more hassle. I'll wait for the real thing.
> Also, I don't like all-in-one granularity. Normally I am not interested at
> all in debug plugins (sadly, there is no support of dbx). I do not want to
> pull and recompile those (and occasionally hit problems) every time I update
> from main repository. My first preference is [component level repos], and
> then [.project level repos] (see bug 316211) organized in sets on component
> level and global CDT level. I am sure there are some more users like me out
> there too.

Using .project level repos, I actually quite like the idea of a single
repo which is tagged and branched atomically (if we can get it built).

Note that although you may clone all of org.eclipse.cdt the directory
hierarchy within it should mean that you needn't _import_ the projects
into your workspace if you don't want to.  There's no need for you to
have plugins / features in your workspace if you're not interested in
We should organise the projects in the repo appropriately so that:
File > Import > Existing Projects ...
will allow you to import feature orthogonally if you so wish, or the
entire CDT project if you select the top-level to search for projects.

Given this having the debug plugins in the repo shouldn't have any
impact on your workflow?


> Andrew
> On Wed, Jun 9, 2010 at 10:32 AM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
>> I propose that we schedule in the move from CVS to Git/Gerrit for late
>> September after the completion of CDT 7.0.1.
>> While we're waiting for that, I'll set up a test server that matches
>> the egit server so that we can get some hands on training with the new
>> system. I'll start with the single repository, org.eclipse.cdt. And as
>> we get experience testing with it, we can try different alternatives
>> as needed.
>> I believe this approach gives us the best balance between the needs to
>> learn about all this stuff, the feature completeness of the egit
>> plug-ins, and disturbance in our schedule. That and I agree with both
>> sentiments that we can't wait another year for this and that we're not
>> ready yet.
>> The great news is that the history seems to come across nicely, so we
>> can stop check-ins one day, and move to git the next. And still have
>> all branches available.
>> Thoughts? -1's?
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx

Back to the top