Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] [GSOC 2013] SnipEditor Weekly Report

Hi,

keeping this on the list as it may be interesting for other gsocers too.


On Sep 10, 2013, at 10:34 PM, Stefan Prisca <stefan.prisca@xxxxxxxxx> wrote:

As far as I know it should. I can't give you an answer at this moment. I did not find the project in that repository though. If I try to access the repository via the browser I get a 404 Not Found error, and when cloning it I only get the snippets, the MANIFEST.MF and an empty src folder. Anyway, I will try to reproduce the scenario and see what happens.

Try this one:
https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.snipmatch.snippets.git





in the meanwhile you have three repositories. Some of them have a test branch and a master. Is there any reason why you don't work on a single repository and on the master branch? It's a bit confusing and changes are hard to find if you change your patterns that often.

Can you make your changes into SnipEditor master branch please?

I used the master branch to keep a more stable build, which sometimes turned out to be a pretty good back-up, and the Test branch to push frequent changes. And, as I separated the project in two and changed the names, I moved it to a different repository (I don't think I had a good reason to do this).I will keep the changes in one branch from now on.


I'd make use of tags rather than having many different branches and repositories. At eclipse the most common approach is as follows: Main development takes place in master branch. Whoever wants the latest and greatest features goes with HEAD (which is usually master). 

Some projects have an integration branch to which project committers commit stable snapshots from time to time for integrators. 

We follow a simpler approach. We only tag our commits and publish snapshots from time to time to different update sites (head, milestones, releases) or maven repositories. I'd suggest that subprojects make use of tags rather than creating different branches as convention

This is at least our current "state-of-the-art" :-)

HTH
Marcel


Back to the top