[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [imp-dev] Re: FYI: IMP SVN repository has been reorganized to "standard" structure
|
Hi,
I'd swap release and feature, such that one can check out an entire set of features that are guaranteed to work together in one go.
After all, that's what the tags are for.
Cheers,
Jurgen
On Sun, Aug 30, 2009 at 12:10 AM, Robert M. Fuhrer
<rfuhrer@xxxxxxxxxxxxxx> wrote:
Ah, good. I was particularly concerned that your critical eye might find fault. :-( / :-)
To be a little more concrete about the release tagging scheme, I'm thinking of the following:
svnroot/technology/org.eclipse.imp
tags
feature1
release1
plugin1
plugin2
...
feature2
release1
plugin1
plugin2
...
release2
plugin1
plugin2
...
...
Sound good?
If people agree, this will be the structure the releng tools will construct (once I get them working again).
On Aug 27, 2009, at 8:57 AM, Jurgen Vinju wrote:
I've used the new situation. No problems detected.
The suggestion to use the feature versions is good, and to copy everything that goes into the feature with it.
Cheers!
Jurgen
On Thu, Aug 27, 2009 at 2:07 AM, Robert M. Fuhrer
<rfuhrer@xxxxxxxxxxxxxx> wrote:
Hi Folks,
While warming up for the next release, I finally got around to reorganizing the IMP SVN repository. The new organization should make the most common case (checking out HEAD of a set of projects on the trunk) much simpler, and aligns the repository with the conventional structure used by other projects.
I believe you should be able to continue to use your existing workspaces, but it might be sensible to start fresh to avoid confusion.
So, instead of:
svnroot/technology/org.eclipse.imp
plugin1
branches
tags
trunk
plugin2
branches
tags
trunk
...
the repository now looks like this:
svnroot/technology/org.eclipse.imp
branches
branch1 - most of these were IMP-wide branches (e.g. "Eclipse-3_2")
plugin1
plugin2
...
branch2
plugin1
plugin2
...
...
tags
OLD
plugin1
tag1 - these were all per-plugin release tags (e.g. "release-0.1.1")
tag2
plugin2
tag1
tag2
...
trunk
plugin1 - all of these are now adjacent (yay!)
plugin2
...
N.B.: The organization of the "tags" folder above reflects the fact that the all of the existing tags were per-plugin, rather than per-feature or IMP-wide. In other words, it didn't make sense to group the 0.1.1's (for instance) together by putting the 0.1.1 at the top level of the "tags" folder.
We now need to decide how to tag the projects on new releases.
I'm leaning toward tagging all of a feature's plugin projects with the feature's version number.
Comments?
_______________________________________________
imp-dev mailing list
imp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/imp-dev