Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Buckminster » SVN provider assumptions...?
SVN provider assumptions...? [message #642814] Thu, 02 December 2010 19:13 Go to next message
Eric Gwin is currently offline Eric GwinFriend
Messages: 10
Registered: July 2009
Junior Member
Hi,

Our project currently uses an Ant/Shell centric build system for automation. I'm investigating Buckminster as a replacement to clean up the provisioning front-end. Our project is in SVN, but am unclear about the some of the assumptions regarding the SVN hierarchy.

Our layout uses trunk/branches/tags, but branches/tags assumes "trunk" as well:
\trunk
\branches\2.0\trunk
\branches\2.1\trunk
\tags\2.0.1-M6\trunk
\tags\2.0.2-M1\trunk

Does this match the assumed scheme, or will I need to rearrange our structure to use the default SVN plugin?

Thanks,
-Eric
Re: SVN provider assumptions...? [message #642821 is a reply to message #642814] Thu, 02 December 2010 19:21 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik LindbergFriend
Messages: 2509
Registered: July 2009
Senior Member
I think that the (unconventional) use of trunk under branches and tags
will cause trouble. What do you gain by having this extra level ?
- henrik

Eric Gwin <eric.gwin@oracle.com> wrote:
> Hi,
>
> Our project currently uses an Ant/Shell centric build system for
> automation. I'm investigating Buckminster as a replacement to clean up
> the provisioning front-end. Our project is in SVN, but am unclear
> about the some of the assumptions regarding the SVN hierarchy.
>
> Our layout uses trunk/branches/tags, but branches/tags assumes "trunk"
> as well:
> \trunk
> \branches\2.0\trunk
> \branches\2.1\trunk
> \tags\2.0.1-M6\trunk
> \tags\2.0.2-M1\trunk
>
> Does this match the assumed scheme, or will I need to rearrange our
> structure to use the default SVN plugin?
> Thanks,
> -Eric


--
- henrik
Re: SVN provider assumptions...? [message #642842 is a reply to message #642814] Thu, 02 December 2010 21:31 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
On 2010-12-02 20:13, Eric Gwin wrote:
> Hi,
>
> Our project currently uses an Ant/Shell centric build system for automation. I'm investigating Buckminster as a
> replacement to clean up the provisioning front-end. Our project is in SVN, but am unclear about the some of the
> assumptions regarding the SVN hierarchy.
>
> Our layout uses trunk/branches/tags, but branches/tags assumes "trunk" as well:
> \trunk
> \branches\2.0\trunk
> \branches\2.1\trunk
> \tags\2.0.1-M6\trunk
> \tags\2.0.2-M1\trunk
>
> Does this match the assumed scheme, or will I need to rearrange our structure to use the default SVN plugin?
> Thanks,
> -Eric

I think the normal way of thinking about it is that you're either on a branch, a tag, or on trunk. I've never
encountered the scheme you're using and I'm afraid it's not supported.

- thomas
Re: SVN provider assumptions...? [message #642847 is a reply to message #642821] Thu, 02 December 2010 22:35 Go to previous messageGo to next message
Eric Gwin is currently offline Eric GwinFriend
Messages: 10
Registered: July 2009
Junior Member
Henrik,

Well, at first we thought that was the convention and it seemed to make sense if one expects to branch from a branch. However, in practice that was never used.

Sounds like it is an item I need to add the the "this needs to change" list.

On the topic of branches, our current practice is to branch per "marketing release". So a phase of development (call it 2.0.0) is coming to a close and we want to prepare for release. We branch to a 2.0 branch (all maintenence patches {2.0.1, 2.0.2, 2.0.3, etc} will reside on this branch), and then begin checking in the new feature work for the next "release" (2.1.0) on trunk.

The sense I get is this isn't the usual practice for an eclipse project. I say this because I can find no 'majic' in the projects I've reviewed to point buckminster to <root>/branches/2.0/... for a 2.0.1 versioned subcomponent. Is this where the use of a "matcher" would need to be used for a svn repository URL? or is there some other mechanism?

-Eric
Re: SVN provider assumptions...? [message #642868 is a reply to message #642847] Fri, 03 December 2010 06:26 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
On 2010-12-02 23:35, Eric Gwin wrote:

> The sense I get is this isn't the usual practice for an eclipse project.
> I say this because I can find no 'majic' in the projects I've reviewed
> to point buckminster to <root>/branches/2.0/... for a 2.0.1 versioned
> subcomponent. Is this where the use of a "matcher" would need to be used
> for a svn repository URL? or is there some other mechanism?
>
Buckminster will always want the URL that contains the 'trunk' keyword.
It then assumes that 'branches' and 'tags' will live adjacent to
'trunk'. What branch or tag (or simply trunk) that is actually used is
controlled by the CQUERY "Branch or Tag" path.

Branches are denoted verbatim, i.e. "2.0.x" whereas tags are denoted
with an initial slash, i.e. "/2.0.1".

So if you have a url like xyz/trunk/something and specify a branch tag
path like /2.0.1 then Buckminster will use xyz/tags/2.0.1/something.
I.e. it replaces the keyword 'trunk' for tags/2.0.1.

If you have a group where you have branches and tags beneath it (like
2.0 in your example), then you can use that too. You would have a
structure like:

xyz/2.0/branches
/2.0.x

xyz/2.0/tags
/2.0.1
/2.0.0

xyz/2.0/trunk

and you pass xyz/2.0/trunk to Buckminster. Doing it that way,
Buckminster wouldn't care about "2.0" and not actually consider it part
of the trunk/branch/tag layout.

A common way of doing this though, would be to no have the "2.0" group
at all and instead do:

xyz/branches/
2.0.x (this is where the next maintenance release for 2.0 is developed)
2.1.x (this is where the next maintenance release for 2.1 is developed)
3.0.x (this is where the next maintenance release for 3.0 is developed)
...

xyz/tags/
2.0.0
2.0.1
2.0.2
2.0.3
2.1.0
2.1.1
2.1.2
3.0.0
3.0.1
...

trunk/

- thomas
Re: SVN provider assumptions...? [message #642951 is a reply to message #642868] Fri, 03 December 2010 13:40 Go to previous message
Eric Gwin is currently offline Eric GwinFriend
Messages: 10
Registered: July 2009
Junior Member
Thanks! The clarification was quite helpful.

-Eric
Previous Topic:Language Fragments missing in the p2 site
Next Topic:The import org.eclipse.swt.ole cannot be resolved (again)
Goto Forum:
  


Current Time: Thu Apr 25 06:52:10 GMT 2024

Powered by FUDForum. Page generated in 0.03655 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top