May 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] Re: String >> #=

by Andres Valloud

String encoding is perpendicular to my point. I'm referring to canonical equivalence as defined in section 1.1 of the document referenced by the URL I sent. For instance, the Hangul example in the first table shows that a combination of two characters (regardless of encoding) is to be considered canonically equivalent to a single character. From the document (which claims to be Unicode Standard Annex #15), "Canonical equivalence is a fundamental equivalency between characters or sequences of characters that represent the same abstract character, and when correctly displayed should always have the same visual appearance and behavior." How do you propose that a size check is appropriate in the presence of canonical equivalence? What is string equivalence supposed to mean? I think more attention should be given to those questions. On 5/27/14 18:53 , Eliot Miranda wrote: > Hi Andres, > > > On Tue, May 27, 2014 at 6:10 PM, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net > <mailto:avalloud@smalltalk.comcastbiz.net>> wrote: > > What is going to happen when one compares two general Unicode series > of characters that represent the same string but differ in > normalization? Wouldn't the size test would result in false negatives? > > http://unicode.org/reports/__tr15/ <http://unicode.org/reports/tr15/> > > I'm asking because I haven't seen any discussion on the subject, and > the decision to change the code as proposed could have side effects. > > > The issue is whether String supports variable-sized encodings such as > UTF-8 where there is no fixed relationship between the number of bytes i > a string and the number of characters in a string. Right now we have > ByteString and WideString. ByteString has 1 byte per character. > WideString has 4 bytes per character. So 'hello' asByteString > contains 5 bytes and has size 5, but 'hello' asWideString contains 20 > bytes and also has size 5. Hence the size check is fine, since size > answers the number of characters, not the number of bytes. If we were > to add a UTF8String we'd have to delete the size check. But I think for > now we're not going to do that. > > A ByteString can contain some characters that comprise a UTF-8 string > (see UTF8TextCoverter) but that's a convention of usage. if you print > some ByteString containing the UTF-8 encoding of a string containing > characters that take more than one byte to encode, that string won't > print as the input, it'll print treating each byte as a character, and > so will scramble the string. It is up to the user to handle these > ByteStrings that happen by convention to contain UTF-8 correctly. > > Note that there is nothing to stop us adding a UTF8String *provided* > that class implements size to answer the number of characters, not the > number of bytes. My understanding is that VW takes this approach also. > File streams expose the encoding, sicne position is a byte position, not > a character position, and so it is up to the file stream client to cope > with the positioning complexities that this introduces, not the stream. > > > OK? > > > > On 5/27/14 11:59 , Eliot Miranda wrote: > > > > > On Tue, May 27, 2014 at 6:54 AM, J. Vuletich (mail lists) > <juanlists(a)jvuletich.org <mailto:juanlists@jvuletich.org> > <mailto:juanlists@jvuletich.__org > <mailto:juanlists@jvuletich.org>>> wrote: > > __ > > Quoting Eliot Miranda <eliot.miranda(a)gmail.com > <mailto:eliot.miranda@gmail.com> > <mailto:eliot.miranda@gmail.__com > <mailto:eliot.miranda@gmail.com>>>: > > Hi Phillipe, > > > On Mon, May 26, 2014 at 12:51 AM, Philippe Marschall > <philippe.marschall(a)netcetera.__ch > <mailto:philippe.marschall@netcetera.ch> > <mailto:philippe.marschall@__netcetera.ch > <mailto:philippe.marschall@netcetera.ch>>> wrote: > > Hi > > I have been investigating why Dictionary look up > performance > with String keys is not as good as I would > expected. Something > I noted is that String >> #= is implemented in terms of > #compare:with:collated:. There is no short circuit > if Strings > are not the same size. In my case some Strings have > the same > prefix but a different length eg 'Content-Type' and > 'Content-Length'. In that case a > #compare:with:collated: is > performed even though we know in advance the answer > will be > false because they have different sizes. > > Why not rewrite > String>>= aString > "Answer whether the receiver sorts equally as aString. > The collation order is simple ascii (with case > differences)." > aString isString ifFalse: [ ^ false ]. > ^ (self compare: self with: aString collated: > AsciiOrder) = 2 > as > String>>= aString > "Answer whether the receiver sorts equally as aString. > The collation order is simple ascii (with case > differences)." > (aString isString > and: [self size = aString size]) ifFalse: [^false]. > ^ (self compare: self withSize: with: aString collated: > AsciiOrder) = 2 > ? > > > > This makes a huge difference, over 3 times faster: > > | bs t1 t2 | > bs := ByteString allInstances first: 10000. > t1 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. > (FileStream fileNamed: > '/Users/eliot/Squeak/Squeak4.__5/String-=.st') fileIn. > t2 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. > { t1. t2 } #(13726 4467) > 4467 - 13726 / 137.26 -67.46% > > One /could/ add a replacement compare:with:collated: > primitive primitiveCompareString which took the sizes > as arguments > to avoid asking twice. But it wouldn't be safe. One > could abuse > the primitive and lie about the size. So I suspect it > is best to > add the size check to String>>#= and accept the > duplication of > the primitive finding the sizes of the two strings. > The cost in > the primitive is minimal. A WideString version of the > primitive > might pay its way, but if Spur and Sista arrive soon > the primitive > shouldn't be faster than the optimised Smalltalk code. > -- > best, > Eliot > > > BTW, any good reason for not prefixing all the implementors > of #= > with this? > > "Any object is equal to itself" > self == argument ifTrue: [ ^ true ]. > > > It doesn't make much difference: > > | bs t1 t2 | > bs := ByteString allInstances first: 10000. > t1 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. > (FileStream fileNamed: > '/Users/eliot/Squeak/Squeak4.__5/String-=.st') fileIn. > t2 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. > { t1. t2 } #(4628 4560) > > 4560 - 4628 / 46.28 -1.47% > > So is it worth it? If you feel it is I've no objection other > than it > feels a little kludgey for such little benefit. And there are the > Symbols if one needs quick comparison and can bear the cost of slow > interning. > -- > best, > Eliot > > > > > > -- > best, > Eliot

May 28, 2014

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Re: String >> #=

by Chris Muller

> On Tue, May 27, 2014 at 6:54 AM, J. Vuletich (mail lists) <juanlists(a)jvuletich.org> wrote: >> >> Quoting Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> Hi Phillipe, >> >> >> On Mon, May 26, 2014 at 12:51 AM, Philippe Marschall <philippe.marschall(a)netcetera.ch> wrote: >>> >>> Hi >>> >>> I have been investigating why Dictionary look up performance with String keys is not as good as I would expected. Something I noted is that String >> #= is implemented in terms of #compare:with:collated:. There is no short circuit if Strings are not the same size. In my case some Strings have the same prefix but a different length eg 'Content-Type' and 'Content-Length'. In that case a #compare:with:collated: is performed even though we know in advance the answer will be false because they have different sizes. >> >> >> Why not rewrite >> >> String>>= aString >> "Answer whether the receiver sorts equally as aString. >> The collation order is simple ascii (with case differences)." >> aString isString ifFalse: [ ^ false ]. >> ^ (self compare: self with: aString collated: AsciiOrder) = 2 >> >> as >> >> String>>= aString >> "Answer whether the receiver sorts equally as aString. >> The collation order is simple ascii (with case differences)." >> >> (aString isString >> and: [self size = aString size]) ifFalse: [^false]. >> ^ (self compare: self withSize: with: aString collated: AsciiOrder) = 2 >> >> ? > > > This makes a huge difference, over 3 times faster: > > | bs t1 t2 | > bs := ByteString allInstances first: 10000. > t1 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. > (FileStream fileNamed: '/Users/eliot/Squeak/Squeak4.5/String-=.st') fileIn. > t2 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. > { t1. t2 } #(13726 4467) > 4467 - 13726 / 137.26 -67.46% >> >> >> One /could/ add a replacement compare:with:collated: primitive primitiveCompareString which took the sizes as arguments to avoid asking twice. But it wouldn't be safe. One could abuse the primitive and lie about the size. So I suspect it is best to add the size check to String>>#= and accept the duplication of the primitive finding the sizes of the two strings. The cost in the primitive is minimal. A WideString version of the primitive might pay its way, but if Spur and Sista arrive soon the primitive shouldn't be faster than the optimised Smalltalk code. >> -- >> best, >> Eliot >> >> BTW, any good reason for not prefixing all the implementors of #= with this? >> >> "Any object is equal to itself" >> self == argument ifTrue: [ ^ true ]. > > > It doesn't make much difference: > > | bs t1 t2 | > bs := ByteString allInstances first: 10000. > t1 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. > (FileStream fileNamed: '/Users/eliot/Squeak/Squeak4.5/String-=.st') fileIn. > t2 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. > { t1. t2 } #(4628 4560) > > 4560 - 4628 / 46.28 -1.47% > > So is it worth it? If you feel it is I've no objection other than it feels a little kludgey for such little benefit. That is a very common convention in the image, not kludgey. String>>#= should advertise, by its implementation, its desire and intent for maximum performance. Not covering this check conveys a lack of thoroghness and/or dedication to performance. Future readers of the method will wonder why such a simple avoidance of unnecessary processing for that case wasn't taken. By the time they wonder whether it was an oversight they've already expended too much thought about it. We should really consider Andres' question before popping this into trunk though.. > And there are the Symbols if one needs quick comparison and can bear the cost of slow interning. > -- > best, > Eliot >

May 28, 2014

MetaRepoForPharo40

by Gabriel Cotelli

Hi, is the Meta Repo for Pharo 4 ready to use? I've configured my jobs in the contribution ci server to run also for Pharo 4. But I can't copy the configuration to the meta repo for Pharo 4 to make it available in the Configuration Browser. Maybe some permissions are missing? Regards, Gabriel

May 28, 2014

Re: [Pharo-dev] [squeak-dev] Re: String >> #=

by Andres Valloud

What is going to happen when one compares two general Unicode series of characters that represent the same string but differ in normalization? Wouldn't the size test would result in false negatives? http://unicode.org/reports/tr15/ I'm asking because I haven't seen any discussion on the subject, and the decision to change the code as proposed could have side effects. On 5/27/14 11:59 , Eliot Miranda wrote: > > > > On Tue, May 27, 2014 at 6:54 AM, J. Vuletich (mail lists) > <juanlists(a)jvuletich.org <mailto:juanlists@jvuletich.org>> wrote: > > __ > > Quoting Eliot Miranda <eliot.miranda(a)gmail.com > <mailto:eliot.miranda@gmail.com>>: > >> Hi Phillipe, >> >> >> On Mon, May 26, 2014 at 12:51 AM, Philippe Marschall >> <philippe.marschall(a)netcetera.ch >> <mailto:philippe.marschall@netcetera.ch>> wrote: >> >> Hi >> >> I have been investigating why Dictionary look up performance >> with String keys is not as good as I would expected. Something >> I noted is that String >> #= is implemented in terms of >> #compare:with:collated:. There is no short circuit if Strings >> are not the same size. In my case some Strings have the same >> prefix but a different length eg 'Content-Type' and >> 'Content-Length'. In that case a #compare:with:collated: is >> performed even though we know in advance the answer will be >> false because they have different sizes. >> >> Why not rewrite >> String>>= aString >> "Answer whether the receiver sorts equally as aString. >> The collation order is simple ascii (with case differences)." >> aString isString ifFalse: [ ^ false ]. >> ^ (self compare: self with: aString collated: AsciiOrder) = 2 >> as >> String>>= aString >> "Answer whether the receiver sorts equally as aString. >> The collation order is simple ascii (with case differences)." >> (aString isString >> and: [self size = aString size]) ifFalse: [^false]. >> ^ (self compare: self withSize: with: aString collated: >> AsciiOrder) = 2 >> ? > > > This makes a huge difference, over 3 times faster: > > | bs t1 t2 | > bs := ByteString allInstances first: 10000. > t1 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. > (FileStream fileNamed: '/Users/eliot/Squeak/Squeak4.5/String-=.st') fileIn. > t2 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. > { t1. t2 } #(13726 4467) > 4467 - 13726 / 137.26 -67.46% > >> One /could/ add a replacement compare:with:collated: >> primitive primitiveCompareString which took the sizes as arguments >> to avoid asking twice. But it wouldn't be safe. One could abuse >> the primitive and lie about the size. So I suspect it is best to >> add the size check to String>>#= and accept the duplication of >> the primitive finding the sizes of the two strings. The cost in >> the primitive is minimal. A WideString version of the primitive >> might pay its way, but if Spur and Sista arrive soon the primitive >> shouldn't be faster than the optimised Smalltalk code. >> -- >> best, >> Eliot > > BTW, any good reason for not prefixing all the implementors of #= > with this? > > "Any object is equal to itself" > self == argument ifTrue: [ ^ true ]. > > > It doesn't make much difference: > > | bs t1 t2 | > bs := ByteString allInstances first: 10000. > t1 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. > (FileStream fileNamed: '/Users/eliot/Squeak/Squeak4.5/String-=.st') fileIn. > t2 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. > { t1. t2 } #(4628 4560) > > 4560 - 4628 / 46.28 -1.47% > > So is it worth it? If you feel it is I've no objection other than it > feels a little kludgey for such little benefit. And there are the > Symbols if one needs quick comparison and can bear the cost of slow > interning. > -- > best, > Eliot

May 28, 2014

Re: [Pharo-dev] Filetree and merging

by Dale Henrichs

On Tue, May 27, 2014 at 1:19 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On 27 May 2014, at 17:09, phil(a)highoctane.be wrote: > > On Tue, May 27, 2014 at 9:21 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> 2014-05-27 20:41 GMT+02:00 Johan Brichau <johan(a)inceptive.be>: >> >>> Have you tried this? >>> >>> https://github.com/ThierryGoubier/GitFileTree-MergeDriver >>> >>> Not sure about the ^M problem though... >>> >>> Johan >>> >>> >> I second this, with GitFileTree it solves most problems of false >> conflicts caused by MC metadata. >> For true conflicts, I did not inquire. >> > > Ok, will have a look. > > At first sight, it looks scary and less friendly than a plain old MCZ > merge. > > But... git is the standard and it is painful to have to maintain things in > two placesâ¦ > > > filetree format is buggy when merging. Reason is is keeping monticello > metadata and that does not plays very good with git (bah, it does not play > good at all). > Well intentionally buggy ... the only reason that the meta data is included in the filetree repo is to play nicely with Monticello - the metadata is required if one expects to copy mcz files into and out of filetree repositories ... it is possible to adopt mcz versions, biut I decided that I would be painfully backward compatible with monticello rather than deal with the chaos that would ensue if one were REQUIRED to adopt the correct versions ... When you yank the monticello meta data you have become committed to using the git repository and that can't be done until the level of tool support in the dev environement is up to snuff ... We are working (Max is doing some work there) in a better integration with > git, where we can drop all those metadata files and rely on git information > (it is there, we just need to use it). But as always, things needs time and > time is scarce :(. > > My recommendation in the mean time is to try gitfiletree. There is a good > chance that it fixes your problems. > Yep, Thierry has done some real good work! Dale

May 27, 2014

Re: [Pharo-dev] Filetree and merging

by Nicolas Cellier

2014-05-27 22:19 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 27 May 2014, at 17:09, phil(a)highoctane.be wrote: > > On Tue, May 27, 2014 at 9:21 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> 2014-05-27 20:41 GMT+02:00 Johan Brichau <johan(a)inceptive.be>: >> >>> Have you tried this? >>> >>> https://github.com/ThierryGoubier/GitFileTree-MergeDriver >>> >>> Not sure about the ^M problem though... >>> >>> Johan >>> >>> >> I second this, with GitFileTree it solves most problems of false >> conflicts caused by MC metadata. >> For true conflicts, I did not inquire. >> > > Ok, will have a look. > > At first sight, it looks scary and less friendly than a plain old MCZ > merge. > > But... git is the standard and it is painful to have to maintain things in > two placesâ¦ > > > filetree format is buggy when merging. Reason is is keeping monticello > metadata and that does not plays very good with git (bah, it does not play > good at all). > As long as the metadata (package ancestry, commit comments, ...) is kept into the image, it plays remarkably well. Good enough to help maintaining Squeak and Pharo projects for ten years or so, as well as a few others (croquet/cobalt, etoys, the VM, etc...) Everything into the image is such a simple model that Pharo now want the whole source in the image rather than in a file, no ;) Yes, these metadata are growing, but I'm pretty sure that this simple model can scale for a few more years. I agree that MC has a problem at server side with files, files make an awfull database! But alternate solutions exist (like magma). MC has another problem with IDs (GUID were not appended to file names, I really don't know why). For packaging an artefact made of several Smalltalk packages, the simplicity of MonticelloConfiguration (MCM) as used in Squeak rocks (simple tools for simple tasks). For me, git make sense for other reasons - mixed language development (like the VM) - visibility, social/collaborative tools like github (pull request, code reviews etc...) - very efficient branching (but it's a false assumption that MC can't do branching, it's more that MCM can't) Git is very powerfull, efficient, light, scales very well, it's from far the best option available for SCM... But in term of simplicity, please think twice for the next generation of in image tools, MC rocks, I wish you invent something as simple and efficient. Nicolas We are working (Max is doing some work there) in a better integration with > git, where we can drop all those metadata files and rely on git information > (it is there, we just need to use it). But as always, things needs time and > time is scarce :(. > > My recommendation in the mean time is to try gitfiletree. There is a good > chance that it fixes your problems. > > Esteban > > > Phil > > >> >> >>> On 27 May 2014, at 20:38, phil(a)highoctane.be wrote: >>> >>> > Hello, >>> > >>> > I am working with Sebastian on some code and we tried out filetree:// >>> > >>> > We have our packages saved there on disk and then we commit/push them >>> on the git server. >>> > >>> > Now, as we develop and then need to merge, I find it hard to do those >>> merges on the .st files. >>> > >>> > As ^M is used as separator, the merge tools seem to have a difficult >>> time and show us 2 huge lines. >>> > >>> > What is the current best practice for merging packages that way? >>> > >>> > TIA >>> > Phil >>> >>> >>> >> > >

May 27, 2014

Re: [Pharo-dev] Filetree and merging

by Dale Henrichs

Johan, >From the GemStone side, tODE has a number of git-friendly features and will be available for alpha real-soon-now[TM] ... I use the tODE git merge tool for all of my git merges as I consider it superior to the existing mergetools out there ... but then I'm biased:) I'm willing to share the fundamental classes for parsing the git merge/diff information if folks from Pharo want to get into that business ... the Metacello Preview features have also been aimed at support for git-based development and I'm leveraging those features for tODE as well ... Dale On Tue, May 27, 2014 at 2:12 PM, Johan Brichau <johan(a)inceptive.be> wrote: > > On 27 May 2014, at 22:09, phil(a)highoctane.be wrote: > > > Ok, will have a look. > > > > At first sight, it looks scary and less friendly than a plain old MCZ > merge. > > > > But... git is the standard and it is painful to have to maintain things > in two places... > > I'm testing the 'git for smalltalk' workflow in the context of our team > because we really want the flexible branching which is non existent in MC. > If you want to have continuous release, a single trunk repository is not > cutting it. Git is good at that and the availability of things like > github/travis/pull requests etc... is also a big plus, although it > certainly is a lot more complex than mcz. > > The GitFiletree mergedriver takes away a lot of the burden when working > with the filetree format. It is a big step forward but imho it will only be > truly used when git is integrated with the Smalltalk IDE for real. > > It works well once you get the hang of it but there are many manual things > to take care of, which is why I'm still reluctant to introduce it fully in > our development flow because making mistakes can easily lead to lost code, > wrong version history, wrong merges, etc... > > So, for now, we use it for experimental branches and we do a manual merge > back into a monticello repository when it needs to go into production. > > De l'expÃ©rimentation quoi.. ;-) > > Johan >

May 27, 2014

Re: [Pharo-dev] Filetree and merging

by phil＠highoctane.be

On Tue, May 27, 2014 at 11:12 PM, Johan Brichau <johan(a)inceptive.be> wrote: > > On 27 May 2014, at 22:09, phil(a)highoctane.be wrote: > > > Ok, will have a look. > > > > At first sight, it looks scary and less friendly than a plain old MCZ > merge. > > > > But... git is the standard and it is painful to have to maintain things > in two places... > > I'm testing the 'git for smalltalk' workflow in the context of our team > because we really want the flexible branching which is non existent in MC. > If you want to have continuous release, a single trunk repository is not > cutting it. Git is good at that and the availability of things like > github/travis/pull requests etc... is also a big plus, although it > certainly is a lot more complex than mcz. > Agreed. We are using GitLab and it rocks! Add to that that a chunk of the application has nothing to do with Smalltalk and is using Bash, Php, and whatnot to get the things done. Git is also great to deploy the stuff on multiple machines. > > The GitFiletree mergedriver takes away a lot of the burden when working > with the filetree format. It is a big step forward but imho it will only be > truly used when git is integrated with the Smalltalk IDE for real. > > It works well once you get the hang of it but there are many manual things > to take care of, which is why I'm still reluctant to introduce it fully in > our development flow because making mistakes can easily lead to lost code, > wrong version history, wrong merges, etc... > Yes, at the moment we save to filetree:// to have a trace in git but the real merge work happens in a MC Repo (FTP w/ user&password), which works nicely enough. > > So, for now, we use it for experimental branches and we do a manual merge > back into a monticello repository when it needs to go into production. > > De l'expÃ©rimentation quoi.. ;-) > I am with you on that. Git is complicated enough without embarking of weird scenarios like that. But for teamwork, this is invaluable. Phil > > Johan >

May 27, 2014

Re: [Pharo-dev] Filetree and merging

by Johan Brichau

On 27 May 2014, at 22:09, phil(a)highoctane.be wrote: > Ok, will have a look. > > At first sight, it looks scary and less friendly than a plain old MCZ merge. > > But... git is the standard and it is painful to have to maintain things in two places... I'm testing the 'git for smalltalk' workflow in the context of our team because we really want the flexible branching which is non existent in MC. If you want to have continuous release, a single trunk repository is not cutting it. Git is good at that and the availability of things like github/travis/pull requests etc... is also a big plus, although it certainly is a lot more complex than mcz. The GitFiletree mergedriver takes away a lot of the burden when working with the filetree format. It is a big step forward but imho it will only be truly used when git is integrated with the Smalltalk IDE for real. It works well once you get the hang of it but there are many manual things to take care of, which is why I'm still reluctant to introduce it fully in our development flow because making mistakes can easily lead to lost code, wrong version history, wrong merges, etc... So, for now, we use it for experimental branches and we do a manual merge back into a monticello repository when it needs to go into production. De l'expÃ©rimentation quoi.. ;-) Johan

May 27, 2014

Re: [Pharo-dev] Filetree and merging

by Esteban Lorenzano

On 27 May 2014, at 17:09, phil(a)highoctane.be wrote: > On Tue, May 27, 2014 at 9:21 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2014-05-27 20:41 GMT+02:00 Johan Brichau <johan(a)inceptive.be>: > Have you tried this? > > https://github.com/ThierryGoubier/GitFileTree-MergeDriver > > Not sure about the ^M problem though... > > Johan > > > I second this, with GitFileTree it solves most problems of false conflicts caused by MC metadata. > For true conflicts, I did not inquire. > > Ok, will have a look. > > At first sight, it looks scary and less friendly than a plain old MCZ merge. > > But... git is the standard and it is painful to have to maintain things in two placesâ¦ filetree format is buggy when merging. Reason is is keeping monticello metadata and that does not plays very good with git (bah, it does not play good at all). We are working (Max is doing some work there) in a better integration with git, where we can drop all those metadata files and rely on git information (it is there, we just need to use it). But as always, things needs time and time is scarce :(. My recommendation in the mean time is to try gitfiletree. There is a good chance that it fixes your problems. Esteban > > Phil > > > On 27 May 2014, at 20:38, phil(a)highoctane.be wrote: > > > Hello, > > > > I am working with Sebastian on some code and we tried out filetree:// > > > > We have our packages saved there on disk and then we commit/push them on the git server. > > > > Now, as we develop and then need to merge, I find it hard to do those merges on the .st files. > > > > As ^M is used as separator, the merge tools seem to have a difficult time and show us 2 huge lines. > > > > What is the current best practice for merging packages that way? > > > > TIA > > Phil > > > >

May 27, 2014