Home » Archived » B3 » branches concrete syntax
|
| Re: branches concrete syntax [message #529290 is a reply to message #529273] |
Fri, 23 April 2010 17:31   |
 Sebastian Zarnekow
Messages: 3118
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 |
Henrik Lindberg
Messages: 2509
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 |
Sebastian Zarnekow
Messages: 3118
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 |
Henrik Lindberg
Messages: 2509
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 |
|
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 |
Henrik Lindberg
Messages: 2509
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 |
Henrik Lindberg
Messages: 2509
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 |
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 |
|
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 |
|
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 |
Sebastian Zarnekow
Messages: 3118
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 |
Henrik Lindberg
Messages: 2509
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 |
Sebastian Zarnekow
Messages: 3118
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 |
Henrik Lindberg
Messages: 2509
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 |
|
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 |
Henrik Lindberg
Messages: 2509
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 |
Henrik Lindberg
Messages: 2509
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 |
|
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 |
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 |
|
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
|
|
|
Goto Forum:
Current Time: Thu Apr 18 11:44:21 GMT 2024
Powered by FUDForum. Page generated in 0.03684 seconds |
] 
Search
Help
Register
Login
Home
