On Wed, Dec 3, 2014 at 8:48 AM, [email protected] <[email protected]> wrote:
> On Wed, Dec 3, 2014 at 7:25 AM, Thierry Goubier <[email protected] > > wrote: > >> >> >> 2014-12-03 4:16 GMT+01:00 Eliot Miranda <[email protected]>: >> >>> >>> Yes, but *I* care about the Monticello metadata. IMO its *better* than >>> the git metadata. >>> >> >> Eliot, you'll have to do better than just IMO on that one. >> >> Some of us work with *both*, and have code for going back and forth, so >> the *better*; bah. >> > > The main issue I have (and I love MCZ to transfer projects around, it is > super easy, especially to patch a running box without fuss). > > Now, the key problem are resource files. I am working on webapps, and you > get javascript, assets (images, css, svgs, mo files, and, in the current > project, other languages running the backend). > It is just a pain to maintain mczs on one side and assets on another one > and keeping it all in sync. > > So, the workflow is to save with filetree:// to have it all, but still > keep and eye on the package-cache/ to pick mczs as needed. > > One important thing to note is that Monticello saves a new mcz with a nice > author+number on each save where filetree:// writes over what is there. So, > if one isn't careful, it is easy to overwrite. > Mczs have saved my butt once or twice here. Kind of a backup mechanism. > > With Mczs, there is also this feeling of being closer to the versions as > they are just there in the environment. > > Both tools have value, and the discussion shouldn't be on what replaces > what, but on how to best complement each other. > > For the record, I use Thierry's merge driver and it makes things smoother. > It took me a while before installing that. And after a couple months of > solid git usage, I am still learning. That's a pain even if the result is > nice. > > FWIW, I have been using a cool command line tool for most of my git work > on servers: tig > http://jonas.nitro.dk/tig/ (runs on ubuntu without problems, has some > conflict with bash-completion on CentOS 6.5 but you can install). > > Try it with: > > tig show > > or > > tig status > > The keybindings are like vim (so: q will get you out of most screens). > > You do a tig status and use 'u' to stage/unstage along with j/k to move > around (or arrows). > > d will give you the diff view, which you can exit with q > > This is the kind of tool we could bring into Pharo and, while not > replacing Monticello, it would complement it magnificently. > Little article on tig: http://blogs.atlassian.com/2013/05/git-tig/ > > Phil > > >> I also happens to know how long it takes to parse hundreds of monticello >> metadata files... and I wasn't impressed with the result. >> >> >>> What's really lacking in Monticello is a) it's not high school so one >>> can't preen in front of the world on github and b) it has no support for >>> external files. Well, a) will be solved by growing up and b) can be solved >>> by building the solution. I know what I'd rather do. >>> >>> >>> [and apologies for being deliberately incendiary but I *hate* the >>> movement away from tools in Squeak/Pharo. It is a movement towards stasis >>> and death, and personally I'm enjoying life too much]. >>> >> >> You then have noticed that those threads are about working on tools? >> >> Thierry >> >> >> >> >
