Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » B3 » branches concrete syntax
branches concrete syntax [message #529273] Fri, 23 April 2010 16:23 Go to next message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
Hi,
After more discussions what needs to be specified around repositories,
fetching, updates, branches etc. I think we have a proposal that works.

Here are some syntax samples:

repositories {
svn myrepo {
remote "svn+ssh://somewhere.org/myrepo";
branches "maintenance-3.5", main tag "release3";
}
svn a.and.b.repo {
remote "...";
branches main exclude "b/*", experiment exclude "a/*";
}
svn myOtherRepo {
remote "...";
branches fix12345 merge, main;
}

Regards
- henrik
Re: branches concrete syntax [message #529290 is a reply to message #529273] Fri, 23 April 2010 17:31 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian Zarnekow
Messages: 2908
Registered: July 2009
Senior Member
Hi Henrik,

could you please explain what this line does:

svn myOtherRepo {
remote "...";
branches fix12345 merge, main; // <- this one
}

I wonder what "fix12345 merge" could mean.

Thanks,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com


Am 23.04.10 18:23, schrieb Henrik Lindberg:
> Hi,
> After more discussions what needs to be specified around repositories,
> fetching, updates, branches etc. I think we have a proposal that works.
>
> Here are some syntax samples:
>
> repositories {
> svn myrepo {
> remote "svn+ssh://somewhere.org/myrepo";
> branches "maintenance-3.5", main tag "release3";
> }
> svn a.and.b.repo {
> remote "...";
> branches main exclude "b/*", experiment exclude "a/*";
> }
> svn myOtherRepo {
> remote "...";
> branches fix12345 merge, main;
> }
>
> Regards
> - henrik
Re: branches concrete syntax [message #529331 is a reply to message #529290] Fri, 23 April 2010 20:29 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
Hi,
"branches" declares the list of branches to search.
In the example "fix12345" is the name of a branch.
this can be followed by a specification of a point on the branch (this
was not illustrated in this example, but it can be one of "tag",
"timestamp", "revision", or the keyword "latest").
The branch "main" is a symbolic branch that denotes the main/trunk.

If nothing is specified, "main" "latest" is assumed.

It is also possible to specify what should be done if the repository is
already represented locally. The choices are "no-update" | "merge" |
"update-unchanged" | "replace-changed" | "fail-changes".

So - the specification in the example means that when a component is
wanted, first look in the branch "fix12345", and perform any merges from
"latest" on this branch if the content has been modified locally, then,
if the wanted component was not found on the fix... branch then look in
main (i.e. trunk since this is svn).

I hope that made it clearer.

- henrik

On 4/23/10 7:31 PM, Sebastian Zarnekow wrote:
> Hi Henrik,
>
> could you please explain what this line does:
>
> svn myOtherRepo {
> remote "...";
> branches fix12345 merge, main; // <- this one
> }
>
> I wonder what "fix12345 merge" could mean.
>
> Thanks,
> Sebastian
Re: branches concrete syntax [message #529332 is a reply to message #529331] Fri, 23 April 2010 20:36 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian Zarnekow
Messages: 2908
Registered: July 2009
Senior Member
Hi Henrik,

thanks for the detailed answer. The problem was that I did not think
about advanced actions on vcs-level to be performed when the component
is resolved.

Thanks,
Sebastian


Am 23.04.10 22:29, schrieb Henrik Lindberg:
> Hi,
> "branches" declares the list of branches to search.
> In the example "fix12345" is the name of a branch.
> this can be followed by a specification of a point on the branch (this
> was not illustrated in this example, but it can be one of "tag",
> "timestamp", "revision", or the keyword "latest").
> The branch "main" is a symbolic branch that denotes the main/trunk.
>
> If nothing is specified, "main" "latest" is assumed.
>
> It is also possible to specify what should be done if the repository is
> already represented locally. The choices are "no-update" | "merge" |
> "update-unchanged" | "replace-changed" | "fail-changes".
>
> So - the specification in the example means that when a component is
> wanted, first look in the branch "fix12345", and perform any merges from
> "latest" on this branch if the content has been modified locally, then,
> if the wanted component was not found on the fix... branch then look in
> main (i.e. trunk since this is svn).
>
> I hope that made it clearer.
>
> - henrik
>
> On 4/23/10 7:31 PM, Sebastian Zarnekow wrote:
>> Hi Henrik,
>>
>> could you please explain what this line does:
>>
>> svn myOtherRepo {
>> remote "...";
>> branches fix12345 merge, main; // <- this one
>> }
>>
>> I wonder what "fix12345 merge" could mean.
>>
>> Thanks,
>> Sebastian
>
Re: branches concrete syntax [message #529336 is a reply to message #529331] Fri, 23 April 2010 20:42 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
Hi again,
Should also add that the defaults for update behavior is that branches
that are not bound to a tag/timestamp/revision have "merge" as the
update policy, and those that are bound have "no-update".

- henrik

On 4/23/10 10:29 PM, Henrik Lindberg wrote:
> Hi,
> "branches" declares the list of branches to search.
> In the example "fix12345" is the name of a branch.
> this can be followed by a specification of a point on the branch (this
> was not illustrated in this example, but it can be one of "tag",
> "timestamp", "revision", or the keyword "latest").
> The branch "main" is a symbolic branch that denotes the main/trunk.
>
> If nothing is specified, "main" "latest" is assumed.
>
> It is also possible to specify what should be done if the repository is
> already represented locally. The choices are "no-update" | "merge" |
> "update-unchanged" | "replace-changed" | "fail-changes".
>
> So - the specification in the example means that when a component is
> wanted, first look in the branch "fix12345", and perform any merges from
> "latest" on this branch if the content has been modified locally, then,
> if the wanted component was not found on the fix... branch then look in
> main (i.e. trunk since this is svn).
>
> I hope that made it clearer.
>
> - henrik
>
> On 4/23/10 7:31 PM, Sebastian Zarnekow wrote:
>> Hi Henrik,
>>
>> could you please explain what this line does:
>>
>> svn myOtherRepo {
>> remote "...";
>> branches fix12345 merge, main; // <- this one
>> }
>>
>> I wonder what "fix12345 merge" could mean.
>>
>> Thanks,
>> Sebastian
>
Re: branches concrete syntax [message #529354 is a reply to message #529273] Fri, 23 April 2010 21:56 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
On 04/23/2010 06:23 PM, Henrik Lindberg wrote:
> Hi,
> After more discussions what needs to be specified around repositories,
> fetching, updates, branches etc. I think we have a proposal that works.
>
> Here are some syntax samples:
>
> repositories {
> svn myrepo {
> remote "svn+ssh://somewhere.org/myrepo";
> branches "maintenance-3.5", main tag "release3";
> }
> svn a.and.b.repo {
> remote "...";
> branches main exclude "b/*", experiment exclude "a/*";
> }
> svn myOtherRepo {
> remote "...";
> branches fix12345 merge, main;
> }
>
I think the syntax is hard to read. It's not intuitive to interpret what 'merge' relates to or that 'main' is the name
of a branch but 'tag', and 'exclude' are keywords. I know how to read it but I'm concerned that it might be hard to grok
for a beginner. Compare the above compact syntax for merge to:

branches fix12345 { update-policy = merge; };

or:

branches "maintenance-3.5", main tag "release3";

to:

branches "maintenance-3.5", main { tag = "release3"; };

or when using all bells and wistles:

branches
"maintenance-3.5" tag "latest" merge include "b.*",
main revision "11456" fail-changes exclude "a.*"

compared to:

branches
"maintenance-3.5" {
tag = "latest";
update-policy = merge;
include = "b.*";
},
main {
revision = "11456";
update-policy = fail;
exclude = "a.*";
}

It's more characters to type and perhaps I'm too influenced with C, Java, PHP, etc. but the latter syntax gives me more
of that warm fuzzy feeling. I look at it and I immediately understand what it says.

- thomas
Re: branches concrete syntax [message #529356 is a reply to message #529354] Fri, 23 April 2010 22:30 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
I agree - hard to read when the list gets longer, and especially without
syntax coloring.

Will use the longer format.
I like "update-policy" as the name of (uh..) the update policy.

Seems like you did not have an allergic reaction to the proposed
update-policy modes.

The only one I am not happy with is "fail-changes". But I have been
considering many alternatives, and the set I like best right now is:

update-policy:
"no-update" | "merge" | "keep-modified"
| "replace-modified" | "fail-modified"
;

(I considered "fail-change", or "fail-changed", "fail-conflicts",
"fail-if-changed", "untampered", "checkedin-only", "repo-only",
"no-local-change", "no-dirty", "no-outgoing", "fail-outgoing", or the
longer "fail-outgoing-change")


- henrik


On 4/23/10 11:56 PM, Thomas Hallgren wrote:
> On 04/23/2010 06:23 PM, Henrik Lindberg wrote:
>> Hi,
>> After more discussions what needs to be specified around repositories,
>> fetching, updates, branches etc. I think we have a proposal that works.
>>
>> Here are some syntax samples:
>>
>> repositories {
>> svn myrepo {
>> remote "svn+ssh://somewhere.org/myrepo";
>> branches "maintenance-3.5", main tag "release3";
>> }
>> svn a.and.b.repo {
>> remote "...";
>> branches main exclude "b/*", experiment exclude "a/*";
>> }
>> svn myOtherRepo {
>> remote "...";
>> branches fix12345 merge, main;
>> }
>>
> I think the syntax is hard to read. It's not intuitive to interpret what
> 'merge' relates to or that 'main' is the name of a branch but 'tag', and
> 'exclude' are keywords. I know how to read it but I'm concerned that it
> might be hard to grok for a beginner. Compare the above compact syntax
> for merge to:
>
> branches fix12345 { update-policy = merge; };
>
> or:
>
> branches "maintenance-3.5", main tag "release3";
>
> to:
>
> branches "maintenance-3.5", main { tag = "release3"; };
>
> or when using all bells and wistles:
>
> branches
> "maintenance-3.5" tag "latest" merge include "b.*",
> main revision "11456" fail-changes exclude "a.*"
>
> compared to:
>
> branches
> "maintenance-3.5" {
> tag = "latest";
> update-policy = merge;
> include = "b.*";
> },
> main {
> revision = "11456";
> update-policy = fail;
> exclude = "a.*";
> }
>
> It's more characters to type and perhaps I'm too influenced with C,
> Java, PHP, etc. but the latter syntax gives me more of that warm fuzzy
> feeling. I look at it and I immediately understand what it says.
>
> - thomas
Re: branches concrete syntax [message #529726 is a reply to message #529356] Tue, 27 April 2010 00:06 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
Hi,
in case you are wondering why this is taking some time to implement...

I ran into several issues:
- generated code was too large to fit within the 64k limit of methods,
and I had to turn on class splitting in Xtext.
- mwe workflow ran out of memory

I got a bunch of strange grammar related errors that sent me off on the
wrong track, but it seems it was related to running out of memory.

- Then ran into issue with using "merge" as a keyword. Turns out this is
the name of a very useful method when dealing with Jobs. Got sidetracked
by error message and by looking at b3 script in editor without syntax
coloring...

r.merge(x);

'syntax error on "." expecting ";" '

duh...

I am now making good progress again after having changed the keyword for
"merge" to "merge-modified".

- henrik

On 4/24/10 12:30 AM, Henrik Lindberg wrote:
> I agree - hard to read when the list gets longer, and especially without
> syntax coloring.
>
> Will use the longer format.
> I like "update-policy" as the name of (uh..) the update policy.
>
> Seems like you did not have an allergic reaction to the proposed
> update-policy modes.
>
> The only one I am not happy with is "fail-changes". But I have been
> considering many alternatives, and the set I like best right now is:
>
> update-policy:
> "no-update" | "merge" | "keep-modified"
> | "replace-modified" | "fail-modified"
> ;
>
> (I considered "fail-change", or "fail-changed", "fail-conflicts",
> "fail-if-changed", "untampered", "checkedin-only", "repo-only",
> "no-local-change", "no-dirty", "no-outgoing", "fail-outgoing", or the
> longer "fail-outgoing-change")
>
>
> - henrik
>
>
> On 4/23/10 11:56 PM, Thomas Hallgren wrote:
>> On 04/23/2010 06:23 PM, Henrik Lindberg wrote:
>>> Hi,
>>> After more discussions what needs to be specified around repositories,
>>> fetching, updates, branches etc. I think we have a proposal that works.
>>>
>>> Here are some syntax samples:
>>>
>>> repositories {
>>> svn myrepo {
>>> remote "svn+ssh://somewhere.org/myrepo";
>>> branches "maintenance-3.5", main tag "release3";
>>> }
>>> svn a.and.b.repo {
>>> remote "...";
>>> branches main exclude "b/*", experiment exclude "a/*";
>>> }
>>> svn myOtherRepo {
>>> remote "...";
>>> branches fix12345 merge, main;
>>> }
>>>
>> I think the syntax is hard to read. It's not intuitive to interpret what
>> 'merge' relates to or that 'main' is the name of a branch but 'tag', and
>> 'exclude' are keywords. I know how to read it but I'm concerned that it
>> might be hard to grok for a beginner. Compare the above compact syntax
>> for merge to:
>>
>> branches fix12345 { update-policy = merge; };
>>
>> or:
>>
>> branches "maintenance-3.5", main tag "release3";
>>
>> to:
>>
>> branches "maintenance-3.5", main { tag = "release3"; };
>>
>> or when using all bells and wistles:
>>
>> branches
>> "maintenance-3.5" tag "latest" merge include "b.*",
>> main revision "11456" fail-changes exclude "a.*"
>>
>> compared to:
>>
>> branches
>> "maintenance-3.5" {
>> tag = "latest";
>> update-policy = merge;
>> include = "b.*";
>> },
>> main {
>> revision = "11456";
>> update-policy = fail;
>> exclude = "a.*";
>> }
>>
>> It's more characters to type and perhaps I'm too influenced with C,
>> Java, PHP, etc. but the latter syntax gives me more of that warm fuzzy
>> feeling. I look at it and I immediately understand what it says.
>>
>> - thomas
>
Re: branches concrete syntax [message #529765 is a reply to message #529273] Tue, 27 April 2010 07:24 Go to previous messageGo to next message
Bernhard Merkle is currently offline Bernhard Merkle
Messages: 88
Registered: July 2009
Member
can we omit some of the keywords, e.g. "remote"
It think usually this is a URL to the repo and this could also be "local" e.g. a file:// url in SVN to a local repository.

So my suggestion would be "url" instead of "remote"
or even better, remove the whole keyword "remote"

also for svn e.g it is quite common to directly specify the branch in the URL, so I am unsure how to handle redundancy vs. ease of use here.

kind regards,
Bernhard.

On 23.04.2010 18:23, Henrik Lindberg wrote:
> Hi,
> After more discussions what needs to be specified around repositories,
> fetching, updates, branches etc. I think we have a proposal that works.
>
> Here are some syntax samples:
>
> repositories {
> svn myrepo {
> remote "svn+ssh://somewhere.org/myrepo";
> branches "maintenance-3.5", main tag "release3";
> }
> svn a.and.b.repo {
> remote "...";
> branches main exclude "b/*", experiment exclude "a/*";
> }
> svn myOtherRepo {
> remote "...";
> branches fix12345 merge, main;
> }
>
> Regards
> - henrik
Re: branches concrete syntax [message #529766 is a reply to message #529726] Tue, 27 April 2010 07:19 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
On 04/27/2010 02:06 AM, Henrik Lindberg wrote:
> - generated code was too large to fit within the 64k limit of methods,
> and I had to turn on class splitting in Xtext.

Uh, is your Mac a 16-bit machine? :D

- thomas
Re: branches concrete syntax [message #529777 is a reply to message #529765] Tue, 27 April 2010 07:58 Go to previous message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
On 04/27/2010 09:24 AM, Bernhard Merkle wrote:
> can we omit some of the keywords, e.g. "remote" It think usually this is
> a URL to the repo and this could also be "local" e.g. a file:// url in
> SVN to a local repository.
>
> So my suggestion would be "url" instead of "remote" or even better,
> remove the whole keyword "remote"
>
I think the motivation for that syntax was to differentiate the "remote" (canonical, central, etc.) repository from the
"local", (clone + checked out) source. But you're right, whatever "remote" is pointing at, may of course be on your
local hard drive so the terms are not perfect. Removing "remote" or calling it "url" does not get my vote since it IMO
reduces the clarity. I also think that the term url incorrect. A CVS repository for instance, uses a syntax that is
neither a URL nor a URI since it stars with a colon.

For SVN and CVS, these terms would work OK:

repository = "svn+ssh://somewhere.org/myrepo";
checkout-location = "/some/path/in/the/filesystem";

For Git however, they don't fit as well since we have a repository to pull from (optionally) and a local repository
(mandatory). So what does the term "repository" mean? We also share the location of the local repository and the
checkout-location. The terms remote and local where the closest ones that we could find that made sense to both the
SVN/CVS and Git scenarios but I agree, perhaps not ideal. Keep the suggestions coming and let's discuss this further.

> also for svn e.g it is quite common to directly specify the branch in
> the URL, so I am unsure how to handle redundancy vs. ease of use here.
>
Yes, that's a problem. In addition, we need to cater for repositories that doesn't have a trunk at all (and of course no
branches or tags). How do I specify a revision in such repository? If we say that "main" is the trunk and there is no
trunk, how do we specify what main is? I guess each repository type must have a set of rules for this.

If the repository does have a standard layout (trunk, branches, tags), then I think we should discourage the use of
direct paths to branches and tags. The reason is that if we have multiple ways of specifying this, then we make it much
harder to write concerns.

Regards,
Thomas Hallgren
Re: branches concrete syntax [message #605982 is a reply to message #529273] Fri, 23 April 2010 17:31 Go to previous message
Sebastian Zarnekow is currently offline Sebastian Zarnekow
Messages: 2908
Registered: July 2009
Senior Member
Hi Henrik,

could you please explain what this line does:

svn myOtherRepo {
remote "...";
branches fix12345 merge, main; // <- this one
}

I wonder what "fix12345 merge" could mean.

Thanks,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com


Am 23.04.10 18:23, schrieb Henrik Lindberg:
> Hi,
> After more discussions what needs to be specified around repositories,
> fetching, updates, branches etc. I think we have a proposal that works.
>
> Here are some syntax samples:
>
> repositories {
> svn myrepo {
> remote "svn+ssh://somewhere.org/myrepo";
> branches "maintenance-3.5", main tag "release3";
> }
> svn a.and.b.repo {
> remote "...";
> branches main exclude "b/*", experiment exclude "a/*";
> }
> svn myOtherRepo {
> remote "...";
> branches fix12345 merge, main;
> }
>
> Regards
> - henrik
Re: branches concrete syntax [message #605985 is a reply to message #529290] Fri, 23 April 2010 20:29 Go to previous message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
Hi,
"branches" declares the list of branches to search.
In the example "fix12345" is the name of a branch.
this can be followed by a specification of a point on the branch (this
was not illustrated in this example, but it can be one of "tag",
"timestamp", "revision", or the keyword "latest").
The branch "main" is a symbolic branch that denotes the main/trunk.

If nothing is specified, "main" "latest" is assumed.

It is also possible to specify what should be done if the repository is
already represented locally. The choices are "no-update" | "merge" |
"update-unchanged" | "replace-changed" | "fail-changes".

So - the specification in the example means that when a component is
wanted, first look in the branch "fix12345", and perform any merges from
"latest" on this branch if the content has been modified locally, then,
if the wanted component was not found on the fix... branch then look in
main (i.e. trunk since this is svn).

I hope that made it clearer.

- henrik

On 4/23/10 7:31 PM, Sebastian Zarnekow wrote:
> Hi Henrik,
>
> could you please explain what this line does:
>
> svn myOtherRepo {
> remote "...";
> branches fix12345 merge, main; // <- this one
> }
>
> I wonder what "fix12345 merge" could mean.
>
> Thanks,
> Sebastian
Re: branches concrete syntax [message #605991 is a reply to message #529331] Fri, 23 April 2010 20:36 Go to previous message
Sebastian Zarnekow is currently offline Sebastian Zarnekow
Messages: 2908
Registered: July 2009
Senior Member
Hi Henrik,

thanks for the detailed answer. The problem was that I did not think
about advanced actions on vcs-level to be performed when the component
is resolved.

Thanks,
Sebastian


Am 23.04.10 22:29, schrieb Henrik Lindberg:
> Hi,
> "branches" declares the list of branches to search.
> In the example "fix12345" is the name of a branch.
> this can be followed by a specification of a point on the branch (this
> was not illustrated in this example, but it can be one of "tag",
> "timestamp", "revision", or the keyword "latest").
> The branch "main" is a symbolic branch that denotes the main/trunk.
>
> If nothing is specified, "main" "latest" is assumed.
>
> It is also possible to specify what should be done if the repository is
> already represented locally. The choices are "no-update" | "merge" |
> "update-unchanged" | "replace-changed" | "fail-changes".
>
> So - the specification in the example means that when a component is
> wanted, first look in the branch "fix12345", and perform any merges from
> "latest" on this branch if the content has been modified locally, then,
> if the wanted component was not found on the fix... branch then look in
> main (i.e. trunk since this is svn).
>
> I hope that made it clearer.
>
> - henrik
>
> On 4/23/10 7:31 PM, Sebastian Zarnekow wrote:
>> Hi Henrik,
>>
>> could you please explain what this line does:
>>
>> svn myOtherRepo {
>> remote "...";
>> branches fix12345 merge, main; // <- this one
>> }
>>
>> I wonder what "fix12345 merge" could mean.
>>
>> Thanks,
>> Sebastian
>
Re: branches concrete syntax [message #605995 is a reply to message #529331] Fri, 23 April 2010 20:42 Go to previous message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
Hi again,
Should also add that the defaults for update behavior is that branches
that are not bound to a tag/timestamp/revision have "merge" as the
update policy, and those that are bound have "no-update".

- henrik

On 4/23/10 10:29 PM, Henrik Lindberg wrote:
> Hi,
> "branches" declares the list of branches to search.
> In the example "fix12345" is the name of a branch.
> this can be followed by a specification of a point on the branch (this
> was not illustrated in this example, but it can be one of "tag",
> "timestamp", "revision", or the keyword "latest").
> The branch "main" is a symbolic branch that denotes the main/trunk.
>
> If nothing is specified, "main" "latest" is assumed.
>
> It is also possible to specify what should be done if the repository is
> already represented locally. The choices are "no-update" | "merge" |
> "update-unchanged" | "replace-changed" | "fail-changes".
>
> So - the specification in the example means that when a component is
> wanted, first look in the branch "fix12345", and perform any merges from
> "latest" on this branch if the content has been modified locally, then,
> if the wanted component was not found on the fix... branch then look in
> main (i.e. trunk since this is svn).
>
> I hope that made it clearer.
>
> - henrik
>
> On 4/23/10 7:31 PM, Sebastian Zarnekow wrote:
>> Hi Henrik,
>>
>> could you please explain what this line does:
>>
>> svn myOtherRepo {
>> remote "...";
>> branches fix12345 merge, main; // <- this one
>> }
>>
>> I wonder what "fix12345 merge" could mean.
>>
>> Thanks,
>> Sebastian
>
Re: branches concrete syntax [message #606001 is a reply to message #529273] Fri, 23 April 2010 21:56 Go to previous message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
On 04/23/2010 06:23 PM, Henrik Lindberg wrote:
> Hi,
> After more discussions what needs to be specified around repositories,
> fetching, updates, branches etc. I think we have a proposal that works.
>
> Here are some syntax samples:
>
> repositories {
> svn myrepo {
> remote "svn+ssh://somewhere.org/myrepo";
> branches "maintenance-3.5", main tag "release3";
> }
> svn a.and.b.repo {
> remote "...";
> branches main exclude "b/*", experiment exclude "a/*";
> }
> svn myOtherRepo {
> remote "...";
> branches fix12345 merge, main;
> }
>
I think the syntax is hard to read. It's not intuitive to interpret what 'merge' relates to or that 'main' is the name
of a branch but 'tag', and 'exclude' are keywords. I know how to read it but I'm concerned that it might be hard to grok
for a beginner. Compare the above compact syntax for merge to:

branches fix12345 { update-policy = merge; };

or:

branches "maintenance-3.5", main tag "release3";

to:

branches "maintenance-3.5", main { tag = "release3"; };

or when using all bells and wistles:

branches
"maintenance-3.5" tag "latest" merge include "b.*",
main revision "11456" fail-changes exclude "a.*"

compared to:

branches
"maintenance-3.5" {
tag = "latest";
update-policy = merge;
include = "b.*";
},
main {
revision = "11456";
update-policy = fail;
exclude = "a.*";
}

It's more characters to type and perhaps I'm too influenced with C, Java, PHP, etc. but the latter syntax gives me more
of that warm fuzzy feeling. I look at it and I immediately understand what it says.

- thomas
Re: branches concrete syntax [message #606003 is a reply to message #529354] Fri, 23 April 2010 22:30 Go to previous message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
I agree - hard to read when the list gets longer, and especially without
syntax coloring.

Will use the longer format.
I like "update-policy" as the name of (uh..) the update policy.

Seems like you did not have an allergic reaction to the proposed
update-policy modes.

The only one I am not happy with is "fail-changes". But I have been
considering many alternatives, and the set I like best right now is:

update-policy:
"no-update" | "merge" | "keep-modified"
| "replace-modified" | "fail-modified"
;

(I considered "fail-change", or "fail-changed", "fail-conflicts",
"fail-if-changed", "untampered", "checkedin-only", "repo-only",
"no-local-change", "no-dirty", "no-outgoing", "fail-outgoing", or the
longer "fail-outgoing-change")


- henrik


On 4/23/10 11:56 PM, Thomas Hallgren wrote:
> On 04/23/2010 06:23 PM, Henrik Lindberg wrote:
>> Hi,
>> After more discussions what needs to be specified around repositories,
>> fetching, updates, branches etc. I think we have a proposal that works.
>>
>> Here are some syntax samples:
>>
>> repositories {
>> svn myrepo {
>> remote "svn+ssh://somewhere.org/myrepo";
>> branches "maintenance-3.5", main tag "release3";
>> }
>> svn a.and.b.repo {
>> remote "...";
>> branches main exclude "b/*", experiment exclude "a/*";
>> }
>> svn myOtherRepo {
>> remote "...";
>> branches fix12345 merge, main;
>> }
>>
> I think the syntax is hard to read. It's not intuitive to interpret what
> 'merge' relates to or that 'main' is the name of a branch but 'tag', and
> 'exclude' are keywords. I know how to read it but I'm concerned that it
> might be hard to grok for a beginner. Compare the above compact syntax
> for merge to:
>
> branches fix12345 { update-policy = merge; };
>
> or:
>
> branches "maintenance-3.5", main tag "release3";
>
> to:
>
> branches "maintenance-3.5", main { tag = "release3"; };
>
> or when using all bells and wistles:
>
> branches
> "maintenance-3.5" tag "latest" merge include "b.*",
> main revision "11456" fail-changes exclude "a.*"
>
> compared to:
>
> branches
> "maintenance-3.5" {
> tag = "latest";
> update-policy = merge;
> include = "b.*";
> },
> main {
> revision = "11456";
> update-policy = fail;
> exclude = "a.*";
> }
>
> It's more characters to type and perhaps I'm too influenced with C,
> Java, PHP, etc. but the latter syntax gives me more of that warm fuzzy
> feeling. I look at it and I immediately understand what it says.
>
> - thomas
Re: branches concrete syntax [message #606050 is a reply to message #529356] Tue, 27 April 2010 00:06 Go to previous message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
Hi,
in case you are wondering why this is taking some time to implement...

I ran into several issues:
- generated code was too large to fit within the 64k limit of methods,
and I had to turn on class splitting in Xtext.
- mwe workflow ran out of memory

I got a bunch of strange grammar related errors that sent me off on the
wrong track, but it seems it was related to running out of memory.

- Then ran into issue with using "merge" as a keyword. Turns out this is
the name of a very useful method when dealing with Jobs. Got sidetracked
by error message and by looking at b3 script in editor without syntax
coloring...

r.merge(x);

'syntax error on "." expecting ";" '

duh...

I am now making good progress again after having changed the keyword for
"merge" to "merge-modified".

- henrik

On 4/24/10 12:30 AM, Henrik Lindberg wrote:
> I agree - hard to read when the list gets longer, and especially without
> syntax coloring.
>
> Will use the longer format.
> I like "update-policy" as the name of (uh..) the update policy.
>
> Seems like you did not have an allergic reaction to the proposed
> update-policy modes.
>
> The only one I am not happy with is "fail-changes". But I have been
> considering many alternatives, and the set I like best right now is:
>
> update-policy:
> "no-update" | "merge" | "keep-modified"
> | "replace-modified" | "fail-modified"
> ;
>
> (I considered "fail-change", or "fail-changed", "fail-conflicts",
> "fail-if-changed", "untampered", "checkedin-only", "repo-only",
> "no-local-change", "no-dirty", "no-outgoing", "fail-outgoing", or the
> longer "fail-outgoing-change")
>
>
> - henrik
>
>
> On 4/23/10 11:56 PM, Thomas Hallgren wrote:
>> On 04/23/2010 06:23 PM, Henrik Lindberg wrote:
>>> Hi,
>>> After more discussions what needs to be specified around repositories,
>>> fetching, updates, branches etc. I think we have a proposal that works.
>>>
>>> Here are some syntax samples:
>>>
>>> repositories {
>>> svn myrepo {
>>> remote "svn+ssh://somewhere.org/myrepo";
>>> branches "maintenance-3.5", main tag "release3";
>>> }
>>> svn a.and.b.repo {
>>> remote "...";
>>> branches main exclude "b/*", experiment exclude "a/*";
>>> }
>>> svn myOtherRepo {
>>> remote "...";
>>> branches fix12345 merge, main;
>>> }
>>>
>> I think the syntax is hard to read. It's not intuitive to interpret what
>> 'merge' relates to or that 'main' is the name of a branch but 'tag', and
>> 'exclude' are keywords. I know how to read it but I'm concerned that it
>> might be hard to grok for a beginner. Compare the above compact syntax
>> for merge to:
>>
>> branches fix12345 { update-policy = merge; };
>>
>> or:
>>
>> branches "maintenance-3.5", main tag "release3";
>>
>> to:
>>
>> branches "maintenance-3.5", main { tag = "release3"; };
>>
>> or when using all bells and wistles:
>>
>> branches
>> "maintenance-3.5" tag "latest" merge include "b.*",
>> main revision "11456" fail-changes exclude "a.*"
>>
>> compared to:
>>
>> branches
>> "maintenance-3.5" {
>> tag = "latest";
>> update-policy = merge;
>> include = "b.*";
>> },
>> main {
>> revision = "11456";
>> update-policy = fail;
>> exclude = "a.*";
>> }
>>
>> It's more characters to type and perhaps I'm too influenced with C,
>> Java, PHP, etc. but the latter syntax gives me more of that warm fuzzy
>> feeling. I look at it and I immediately understand what it says.
>>
>> - thomas
>
Re: branches concrete syntax [message #606055 is a reply to message #529726] Tue, 27 April 2010 07:19 Go to previous message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
On 04/27/2010 02:06 AM, Henrik Lindberg wrote:
> - generated code was too large to fit within the 64k limit of methods,
> and I had to turn on class splitting in Xtext.

Uh, is your Mac a 16-bit machine? :D

- thomas
Re: branches concrete syntax [message #606058 is a reply to message #529273] Tue, 27 April 2010 07:24 Go to previous message
Bernhard Merkle is currently offline Bernhard Merkle
Messages: 88
Registered: July 2009
Member
can we omit some of the keywords, e.g. "remote"
It think usually this is a URL to the repo and this could also be "local" e.g. a file:// url in SVN to a local repository.

So my suggestion would be "url" instead of "remote"
or even better, remove the whole keyword "remote"

also for svn e.g it is quite common to directly specify the branch in the URL, so I am unsure how to handle redundancy vs. ease of use here.

kind regards,
Bernhard.

On 23.04.2010 18:23, Henrik Lindberg wrote:
> Hi,
> After more discussions what needs to be specified around repositories,
> fetching, updates, branches etc. I think we have a proposal that works.
>
> Here are some syntax samples:
>
> repositories {
> svn myrepo {
> remote "svn+ssh://somewhere.org/myrepo";
> branches "maintenance-3.5", main tag "release3";
> }
> svn a.and.b.repo {
> remote "...";
> branches main exclude "b/*", experiment exclude "a/*";
> }
> svn myOtherRepo {
> remote "...";
> branches fix12345 merge, main;
> }
>
> Regards
> - henrik
Re: branches concrete syntax [message #606060 is a reply to message #606058] Tue, 27 April 2010 07:58 Go to previous message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
On 04/27/2010 09:24 AM, Bernhard Merkle wrote:
> can we omit some of the keywords, e.g. "remote" It think usually this is
> a URL to the repo and this could also be "local" e.g. a file:// url in
> SVN to a local repository.
>
> So my suggestion would be "url" instead of "remote" or even better,
> remove the whole keyword "remote"
>
I think the motivation for that syntax was to differentiate the "remote" (canonical, central, etc.) repository from the
"local", (clone + checked out) source. But you're right, whatever "remote" is pointing at, may of course be on your
local hard drive so the terms are not perfect. Removing "remote" or calling it "url" does not get my vote since it IMO
reduces the clarity. I also think that the term url incorrect. A CVS repository for instance, uses a syntax that is
neither a URL nor a URI since it stars with a colon.

For SVN and CVS, these terms would work OK:

repository = "svn+ssh://somewhere.org/myrepo";
checkout-location = "/some/path/in/the/filesystem";

For Git however, they don't fit as well since we have a repository to pull from (optionally) and a local repository
(mandatory). So what does the term "repository" mean? We also share the location of the local repository and the
checkout-location. The terms remote and local where the closest ones that we could find that made sense to both the
SVN/CVS and Git scenarios but I agree, perhaps not ideal. Keep the suggestions coming and let's discuss this further.

> also for svn e.g it is quite common to directly specify the branch in
> the URL, so I am unsure how to handle redundancy vs. ease of use here.
>
Yes, that's a problem. In addition, we need to cater for repositories that doesn't have a trunk at all (and of course no
branches or tags). How do I specify a revision in such repository? If we say that "main" is the trunk and there is no
trunk, how do we specify what main is? I guess each repository type must have a set of rules for this.

If the repository does have a standard layout (trunk, branches, tags), then I think we should discourage the use of
direct paths to branches and tags. The reason is that if we have multiple ways of specifying this, then we make it much
harder to write concerns.

Regards,
Thomas Hallgren
Previous Topic:in search for a term - opinions wanted
Next Topic:Helios release was successfully built with b3 aggregator
Goto Forum:
  


Current Time: Fri Oct 24 08:03:19 GMT 2014

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

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