--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metacello+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I am not completely opposed to your proposal, but having a single string specification for the repo is awfully convenient ....
What are the specific urls and problems that you are having ... it may be that we can keep the strings and find other ways to solve the problems?
Like I don't think that it is necessary to have the disk format included in the url ... perhaps we should have a "filetree format decoder" that allows the the platform to figure out which repository reader to use ... the `.filetree` properties file was always conceived of as the place where information could stashed that allowed readers to figure out what disk format the repository is ... we could change the name to something like `.repository` and simply include the format field ... no .repository file implies filetree ... and so one ...
Are there other issues that you are thinking about?
Dale
--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metacello+...@googlegroups.com.
Phil,
I will ask you the same question. What is "not clear and hard"
that you are thinking about ...
I get the sense that there must be a proliferation of urls in the pharo universe that I am not aware, so I'd like to see some examples of these different urls.
I know that in some of my current development work I have a similar proliferation of urls and I am personally leaning to NOT using an url to denote either the type of repository and/or the platform implementation being used to manage the git repos ...
my preference is to retain the github:// style --- using the
provider to distinguish where to download the url and then to use
platform-specific url handlers (which can be customized by
developers) to determine which tool to use to manage the
repository ... a discussion along these lines has been started
here[1] ...
I think it is a mistake to encode the disk format in the Metacello spec ... the disk format can change from commit to commit and the Metcello spec should not have to change if the format of the repo chenages especially when the format can change from commit to commit ...
I would like to see specific issues described so that we have a chance to be clear on exactly which problem(s) we are solving BEFORE starting to come up with solutions...
Dale
To unsubscribe from this group and stop receiving emails from it, send an email to metacello+...@googlegroups.com.
Here is an almost complete list of urls that have come up during the cypress/cypress2 (alternate filetree reader/loader/writer to Monticello):
'tonel:<dirpath>'
'cypress:<dirpath>'
'cypressft:<dirpath>'
Okay this would be an interesting url to support ... and this is
a case where branch and directory info is missing:
g...@git.gemtalksystems.com:GsDevKit_sys_local.git
Phil,
I will ask you the same question. What is "not clear and hard" that you are thinking about ...
I get the sense that there must be a proliferation of urls in the pharo universe that I am not aware, so I'd like to see some examples of these different urls.
I know that in some of my current development work I have a similar proliferation of urls and I am personally leaning to NOT using an url to denote either the type of repository and/or the platform implementation being used to manage the git repos ...
my preference is to retain the github:// style --- using the provider to distinguish where to download the url and then to use platform-specific url handlers (which can be customized by developers) to determine which tool to use to manage the repository ... a discussion along these lines has been started here[1] ...
I think it is a mistake to encode the disk format in the Metacello spec ... the disk format can change from commit to commit and the Metcello spec should not have to change if the format of the repo chenages especially when the format can change from commit to commit ...
I would like to see specific issues described so that we have a chance to be clear on exactly which problem(s) we are solving BEFORE starting to come up with solutions...
Dale
[1] https://github.com/Metacello/metacello/issues/474
On 22 Dec 2017, at 19:37, Dale Henrichs <dale.h...@gemtalksystems.com> wrote:Okay this would be an interesting url to support ... and this is a case where branch and directory info is missing:
Cyril,
How are these projects cloned when using the git command line? Examples
of the command line would be good enough ...
Dale
Esteban,
Cyril has started a discussion on the pharo list about extending ZnUrl to permit custom url parsing.
I have heard that you guys are using regex for parsing iceberg
repository descriptions and I am curious which urls you are using
regex for?