FreewayTalk

22 replies to this thread. Most Recent

Todd

24 Sep 2013, 3:56 pm

Freeway + Git = Fun or Futility?

I’m lovin’ Git and version control in general, it’s going to save my toches.

Wait, what’s Git?

Git (and Subversion, Mercurial etc.) are VCS or Version Control Systems. They allow you to track every-single-change made to a file so you can roll back to a previous version or branch and merge files at will. They can be used by a single person or within a collaborative environment. Think of it as “multiple undos” on steroids.

Enter Freeway

Well, curiosity has gotten the better of me (again) and I’ve been wondering how it would work within a FW workflow. Truthfully I already had a good idea where it would end up but I wanted to see for myself. The bottom line is that it works great … to a point, and is easy to setup. The problem, as expected, is that if you roll back to an earlier version of say, your index.html file, there’s no way to update the actual Freeway file to reflect the revision so any changes you make in the FW doc will overwrite the previous version you just rolled back to.

Ok, so what’s the point?

I’m not entirely sure. One benefit is that you’ll have an ongoing and detailed repository of all your work that you can easily access should you make a critical error; it’s the perfect safety net. Using FW with Git can still be beneficial (I can think of a couple ways that it could work) albeit in a clumsy way and certainly not in the manner in which a VCS is designed to work. Still, for some it might warrant further investigation.

If some FW users are interested I just might be persuaded to put together a how-to, and you can explore it for yourself and make your own decision. Let me know here or off-list.

Todd http://xiiro.com

stewart

24 Sep 2013, 4:07 pm

On 24/09/2013 16:56, Todd wrote:

The problem, as expected, is that if you roll back to an earlier version of say, your index.html file, there’s no way to update the actual Freeway file to reflect the revision so any changes you make in the FW doc will overwrite the previous version you just rolled back to.

Well, there’s no reason you couldn’t keep your FW document as part of the git repository as well. Or indeed just track the Freeway document, and then checkout and republish as you wish. You’d probably want to create an alias in your Actions directory pointing to a directory of Actions which is also tracked by git, so as to provide the same output through Action install/uninstall.

Stewart

waltd

24 Sep 2013, 4:10 pm

True, but you would lose much of the benefit of Git when you did. The Freeway document is a big-ass binary file, and Git works best with collections of text files, where it can find just the few bits that changed in a few sub-files, and mark (and store diffs of) those changes. It would be just like keeping Photoshop files in Git.

Walter

On Sep 24, 2013, at 12:06 PM, Stewart Fellows wrote:

On 24/09/2013 16:56, Todd wrote:

The problem, as expected, is that if you roll back to an earlier version of say, your index.html file, there’s no way to update the actual Freeway file to reflect the revision so any changes you make in the FW doc will overwrite the previous version you just rolled back to.

Well, there’s no reason you couldn’t keep your FW document as part of the git repository as well. Or indeed just track the Freeway document, and then checkout and republish as you wish. You’d probably want to create an alias in your Actions directory pointing to a directory of Actions which is also tracked by git, so as to provide the same output through Action install/uninstall.

Stewart

Freeway user since 1997

http://www.walterdavisstudio.com

Todd

24 Sep 2013, 4:21 pm

I guess that’s what LayerVault is for https://layervault.com

Todd http://xiiro.com

It would be just like keeping Photoshop files in Git.

Todd

24 Sep 2013, 4:39 pm

Ok, but for the sake of exploring the options could Stewart’s suggestion be a valid alternative to the oft-requested “multiple undos”? If so (big “if”) that could be a very compelling reason to adopt a Git-based workflow with FW.

Todd http://xiiro.com

True, but you would lose much of the benefit of Git when you did.

waltd

24 Sep 2013, 4:42 pm

It’s a worthy experiment. PDI, as they used to say on the Rails mailing list…

Walter

(Please Do Implement)

On Sep 24, 2013, at 12:39 PM, Todd wrote:

Ok, but for the sake of exploring the options could Stewart’s suggestion be a valid alternative to the oft-requested “multiple undos”? If so (big “if”) that could be a very compelling reason to adopt a Git-based workflow with FW.

Todd http://xiiro.com

True, but you would lose much of the benefit of Git when you did.

Freeway user since 1997

http://www.walterdavisstudio.com

Todd

24 Sep 2013, 4:44 pm

I’m on it.

Todd http://xiiro.com

It’s a worthy experiment. PDI, as they used to say on the Rails mailing list…

Todd

24 Sep 2013, 5:43 pm

A cursory attempt at tracking the FW doc. is proving somewhat successful (if a bit confusing) but it seems finicky and I’m not sure I completely grasp how FW is “seeing” the old versions (rollbacks). Not sure if it’s a FW or Git thing. I do think it’s worth investigating further before I give up, but maybe someone with more FW experience than myself should also look into it.

Todd http://xiiro.com

It’s a worthy experiment. PDI, as they used to say on the Rails mailing list…

Walter

(Please Do Implement)

Todd

24 Sep 2013, 7:43 pm

At the risk of speaking prematurely I’ve spent more time with this and I now have a somewhat viable (if not perfect) integration of Git and Freeway that allows for rolling the FW doc (and the generated .html files) back to any previous version. In other words, it’s multiple undos (sort of) … Git-style.

More testing needs to be done because there are rough spots - it doesn’t work as smoothly as when using Git with an editor and individual files - though someone else may be able to see a way to improve the FW process.

It’s still a proof-of-concept but it’s pretty damn cool. Revision control with FW! That’s (potentially) a big deal.

Todd http://xiiro.com

It’s a worthy experiment. PDI, as they used to say on the Rails mailing list…

waltd

24 Sep 2013, 7:47 pm

Todd, is the issue getting Freeway to open a document that you’ve rolled back? Does the file seem to lose its Type and Creator metadata and become an anonymous file that you can’t double-click to open?

Walter

On Sep 24, 2013, at 3:43 PM, Todd wrote:

More testing needs to be done because there are rough spots - it doesn’t work as smoothly as when using Git with an editor and individual files - though someone else may be able to see a way to improve the FW process.

Freeway user since 1997

http://www.walterdavisstudio.com

Todd

24 Sep 2013, 7:57 pm

I’ve not had any issues opening a file (yet), but there has been some inconsistencies with how FW “sees” a rolled-back FW doc. With the FW file open, after a rollback sometimes the revision will just appear in FW without any meddling from me, but usually it requires closing the doc and reopening the file before FW recognizes it. I’m not sure why it’s like that but if we can consistently make FW see the revision automatically that would be, well, great.

Todd http://xiiro.com

Todd, is the issue getting Freeway to open a document that you’ve rolled back? Does the file seem to lose its Type and Creator metadata and become an anonymous file that you can’t double-click to open?

waltd

24 Sep 2013, 8:04 pm

Oh wow, I wasn’t imagining you would be able to do that at all. I know nothing concrete about how Freeway handles files, but from my years of experience with Mac desktop apps, it generally goes like this:

  1. Open a file. As much of it as is needed is read into memory. Depending on the data model, this may be all of the file or a subset of it. As you move through the document, more and more of it is read into memory if it isn’t there already.
  2. Any changes you make to the document are done to the in-memory copy only.
  3. Only when you invoke the Save command does the disk copy get updated, and the in-memory version and the disk are (briefly) in sync.

I would be startled if Freeway took kindly to its disk data version suddenly shifting below its feet while the in-memory copy was open for writing. Joe or Stewart, can you chime in on this?

Walter

On Sep 24, 2013, at 3:57 PM, Todd wrote:

I’ve not had any issues opening a file (yet), but there has been some inconsistencies with how FW “sees” a rolled-back FW doc. With the FW file open, after a rollback sometimes the revision will just appear in FW without any meddling from me, but usually it requires closing the doc and reopening the file before FW recognizes it. I’m not sure why it’s like that but if we can consistently make FW see the revision automatically that would be, well, great.

Todd http://xiiro.com

Todd, is the issue getting Freeway to open a document that you’ve rolled back? Does the file seem to lose its Type and Creator metadata and become an anonymous file that you can’t double-click to open?

Freeway user since 1997

http://www.walterdavisstudio.com

Todd

24 Sep 2013, 8:09 pm

It’s exciting progress. But this inconsistency is difficult to troubleshoot.

Todd http://xiiro.com

Oh wow, I wasn’t imagining you would be able to do that at all. I know nothing concrete about how Freeway handles files, but from my years of experience with Mac desktop apps, it generally goes like this:

  1. Open a file. As much of it as is needed is read into memory. Depending on the data model, this may be all of the file or a subset of it. As you move through the document, more and more of it is read into memory if it isn’t there already.
  2. Any changes you make to the document are done to the in-memory copy only.
  3. Only when you invoke the Save command does the disk copy get updated, and the in-memory version and the disk are (briefly) in sync.

I would be startled if Freeway took kindly to its disk data version suddenly shifting below its feet while the in-memory copy was open for writing. Joe or Stewart, can you chime in on this?

Walter

On Sep 24, 2013, at 3:57 PM, Todd wrote:

I’ve not had any issues opening a file (yet), but there has been some inconsistencies with how FW “sees” a rolled-back FW doc. With the FW file open, after a rollback sometimes the revision will just appear in FW without any meddling from me, but usually it requires closing the doc and reopening the file before FW recognizes it. I’m not sure why it’s like that but if we can consistently make FW see the revision automatically that would be, well, great.

Todd http://xiiro.com

Todd, is the issue getting Freeway to open a document that you’ve rolled back? Does the file seem to lose its Type and Creator metadata and become an anonymous file that you can’t double-click to open?

Todd

24 Sep 2013, 8:20 pm

The more I rollback it’s becoming clear that simply closing/reopening the file is the way to refresh it. I’ve not seen it update automatically in the last dozen rollbacks I’ve tried so maybe it was a fluke. It’s not a terrible extra step to close/reopen; pretty quick and painless, really, if not ideal. All-in-all it’s been working beautifully so far: rollback, commit, push and with a little auto-deploy thrown in … boom updated site.

Is this good news, or what?

Todd http://xiiro.com

Oh wow, I wasn’t imagining you would be able to do that at all.

Joe Billings

25 Sep 2013, 8:58 am

Nice, Todd! You could always try the File>Revert to Saved menu option. That will close the file and reopen the version on disk without quitting Freeway.

Joe

On 24 Sep 2013, at 21:20, Todd <[email protected]> wrote:

The more I rollback it’s becoming clear that simply closing/reopening the file is the way to refresh it.

Joe Billings

Freeway & Exhibeo: Visual web design apps for Mac


http://www.softpress.com

stewart

25 Sep 2013, 9:06 am

On 24/09/2013 21:04, Walter Lee Davis wrote:

I would be startled if Freeway took kindly to its disk data version suddenly shifting below its feet while the in-memory copy was open for writing. Joe or Stewart, can you chime in on this?

I’m not going to commit 100% to this, but I think the only things Freeway reads from the file after the document has fully opened are cached resources, however this would, I imagine, cause some problems for it. I would certainly recommend closing and reopening the document after changing revisions.

Stewart

Todd

25 Sep 2013, 8:37 pm

Thanks Joe.

Since it’s pretty easy to set-up I hope others here (specifically the people who always ask/complain about the lack of multiple undos) will take some time and experiment with it, I would be curious to know if my results are consistent with other users and if it could be further refined to be a practical and usable FW workflow. It’s not perfect but it would seem to have the potential to be a genuinely viable alternative to multiple undos. Plus Git has certainly found its way into the modern web development workflow. Maybe it’s time.

Todd http://xiiro.com

Nice, Todd! You could always try the File>Revert to Saved menu option. That will close the file and reopen the version on disk without quitting Freeway.

waltd

25 Sep 2013, 8:40 pm

Actions can call shell commands. Maybe someone would like to write one that could call the various git commands (init, status, add, commit) from the Actions palette? Not sure how the return value would work in the Action interface, but that could be a fun experiment. I don’t have time this week to tackle this.

Walter

On Sep 25, 2013, at 4:36 PM, Todd wrote:

Thanks Joe.

Since it’s pretty easy to set-up I hope others here (specifically the people who always ask/complain about the lack of multiple undos) will take some time and experiment with it, I would be curious to know if my results are consistent with other users and if it could be further refined to be a practical and usable FW workflow. It’s not perfect but it would seem to have the potential to be a genuinely viable alternative to multiple undos. Plus Git has certainly found its way into the modern web development workflow. Maybe it’s time.

Todd http://xiiro.com

Nice, Todd! You could always try the File>Revert to Saved menu option. That will close the file and reopen the version on disk without quitting Freeway.

Freeway user since 1997

http://www.walterdavisstudio.com

Todd

3 Oct 2013, 6:30 am

Alright Thomas (and anyone else who may be following along), here’s my process for setting up local and remote repositories with Bitbucket and your Git client of choice (though you can also use Terminal) with Freeway Pro. I have no doubt that I’ve overlooked something (possibly a lot) so don’t shoot the messenger, it’s late and I’m tired. I’ll try to answer any questions but I hope others will chime in too.

At first glance this may seem like an awful lot of work to setup but it’s really not. The confusing part might be generating the SSH keys and installing the deploy script, neither of which is difficult. But those things only need to be done once. Set it and forget it. The next time you create a repo it should take less than 5 minutes.

Keep in mind that whatever problems you (and I) experience in getting Freeway to play nicely with Git (and there are problems) it’s not representative of how Git works with more typical simple text files. Freeway was never intended to lend itself to this type of workflow by default which is normally a very smooth and painless process. What I’m trying to do with FW is akin to the round hole/square peg scenario.

  • Note that this same setup will work with non-Freeway workflows. Use it anywhere.

What you need:

  • A free Bitbucket account https://bitbucket.org. * GitHub will also work great and should be fairly similar to setup but this tutorial is specific to Bitbucket.

  • Terminal (command line).

  • Optional Git client. I use Coda but there are numerous options from SourceTree, Gitbox, GitX, SmartGit, Tower etc.

  • SSH access to your server. You’ll need to know the SSH settings.

Let’s go …

Where To Put Your Local Repo

First you need to decide where you want to install your local repo. If you’re tracking a FW site then the decision has already been made for you: the repo should be created in the same folder as your Freeway (.freeway) document, not in the Site Folder. You need to set Freeway’s publish location to the folder that contains the actual Freeway file. Also, if the folder already contains files then you need to first move everything out, we want to start with a completely empty folder. You’ll move the files back once the repo is installed.

Important! Here’s where things get finicky when doing this sort of thing with Freeway. Because of how FW works (it generates site files from the master FW doc) we only want to keep track of changes to the FW document, not the html/css/js files it creates. Understand this is somewhat counter-intuitive to how we would typically use a VCS like Git. Nevertheless, since we don’t want to track the individual files (this could potentially cause problems when rolling back to a previous version) we need to tell git to ignore them. This means every page we create going forward should probably be added to the .gitignore list (see below). Clumsy yes, but probably necessary, at least as far as I can tell. Though I hope I’m wrong.

HTTPS or SSH

Depending on what you prefer there are 2 options for communicating with Bitbucket: HTTPS and SSH. I use SSH in this example but HTTPS may be easier if you’re just testing the waters, though I haven’t used it. Read more about each here https://confluence.atlassian.com/pages/viewpage.action?pageId=270827678.

  • Note that if you go with SSH you’ll want to generate keys for your local machine as well as your remote server and each of these keys will need to be saved in your Bb account under Manage Account > SSH keys

Creating Your First Repository

  1. Create a Bitbucket account.
  2. On your Dashboard page on the right sidebar click the “Create a repository” link.
  3. Fill in the required “Name” field and in the “Language” picker choose an option (in this case “HTML/CSS”).
  4. Click the blue “Create repository” button. Once do this you will be presented with 2 options for creating your repo.
  5. Choose “Start from scratch” and open the Terminal to create a local session.
  6. Follow the instructions for setting up your local repo and be sure to click the blue “Next” button after you complete each of the sections.
  7. At this point you should now have a functioning Git repo (.git) on your local computer in whatever folder you specified. It won’t be visible by default so enable viewing invisible files.
  8. If you see the .git folder go ahead and move any files back into the parent folder (i.e. the folder where your site files will live), not the .git folder. Your files should now be tracked and if everything is working properly then you should be able to “add” and “commit” any changes you make to your file(s) and “push” those changes to your Bb repo.

(Optional) If you’re using Coda’s built-in Git feature then at this stage it should already “see” your repo so go into the Site settings and under the “Source” tab the picker should already be set to “Local” and the “Branches” field should have “master” in it. The other fields should be blank. Now toggle the switch to “On”. That’s it, you’re live and in color.

Ignoring Files * Chances are you don’t want to track everything so we can now tell git what folders/files to ignore. Remember what I said above about ignoring FW’s generated site files?

  1. Manually create a file named .gitignore and place it your local site root. Add any folders/files you want to ignore.

Basic example:

file_names.html .DS_Store folder_names_end_with_a_forward_slash/

Cloning Your Bitbucket Repo On The Remote Server * Local changes are not yet being posted to your server because we haven’t setup a clone of the Bb repo on the remote server.

  1. In your Bb account, in the upper “Repositories” drop-down menu select the repo you created.
  2. On the repo page at the top of the right sidebar you’ll see a small picker with options “SSH” and “HTTPS”.
  3. Select “SSH” and copy the text in the text field next to the picker.
  4. Open a new Terminal session but this time you need to access the remote server via SSH.
  5. Once you connect to your server via SSH (you should be in the site root, e.g. public_html) type the following command and paste the repo text you just copied. You should end up with something that looks like the following, except with your account details:
git clone [email protected]:MyUsername/my_repo_name.git
  1. Hit Return in the Terminal and it will duplicate your Bb repo in the public directory of your server.
  • Whatever you named your Bb repo when you first created it, e.g. “myrepo”, there should now be a folder on your server named “myrepo”. Inside that folder it will be the (invisible) .git repo folder:

myrepo .git

  1. Move the .git folder out and place it in the site root. The repo folder should now be empty and you can delete it.
  • You now have an exact clone of the repo that’s in your Bb account and on your local machine. At this point you can manually “pull” your changes from Bb to your server but who wants to do that? So let’s automate this last part.

Auto-deploy

  1. Copy this script http://jamescollings.co.uk/blog/bitbucket-deployment-script/ into a php file and be sure to add your Bb account details at the top of the script. Name the file whatever you like and put it in the site root (remote).
  2. Go back to your repo account page and click on the blue “cog” icon and select “Hooks” from the left menu.
  3. From the “Select a hook…” picker choose “POST” then click “Add Hook”.
  4. In the text field enter the full url to the script file, e.g. http://mysite.com/auto-deploy.php
  • If all is groovy then each time you push your local changes to Bb it will automagically send those changes to your server with no further effort on your part. Easy, ain’t it? Now you have an ongoing record of every change you make to your files with the ability to rollback to any previous version.

Todd http://xiiro.com

Thomas Kimmich

5 Oct 2013, 2:08 pm

After this great tut, it’s my turn now to rush in. I’ll for sure take your route, but for shorten this all up, I use GitHub and its own native app (no terminal required and nice looking http://www.evernote.com/shard/s246/sh/3a472f7a-6011-4d9e-8420-a83fa8ea60f8/34ebfcb0be6439cdb779302d8fa3cc35 ).

Known CAVEAT on github:

No private repos for FREE. So let’s create a public one.

After app. 20 min I got it:

https://github.com/Kimmich-DigitalMedia/Freeway-GitHub-testimonials

OK - I’m sure I miss a lot but it is a pretty good start.

The Idea behind:

I am making screencasts. Nothing spectacular, rather bad english but with love to details - most paid, some free. The StoneOven Template is a new series I already started to go bit more in detail and cover some more important things in a live-dev surrounding.

A subscriber will learn, but everyone has got the chance to investigate the file.

I’m not free of mistakes so it would be even possible that someone forks this buddy, making his own repos and pulls the changes.

Each screencast episode will end in commit and step by step the “template” will be developed up to a final re-usable version.

Still some work to do to close the gap between the current stat and the screencast progress.

MY FIRST BIGGER TROUBLE:

Committing a FW-file has the caveat of the “upload-details” which are naturally transported with the file. So I have to make sure to remove them before commit or to update it via FTP client and never fill them in (unwanted) as it is a live-project naturally.

THE MULTIPLE UNDOS (the main idea of this thread)

Oh gosh yeahh - I haven’t figured out this yet. The GitApp seems to keep just the latest save but not a “list of history” to step back in file-history. Hmmm - I have to mind about this.

Cheers

Thomas

Thomas Kimmich

Kimmich DigitalMedia

http://www.kimmich-digitalmedia.com

T.+49(0)7404-914 384

Somewhere in the South of Germany

waltd

5 Oct 2013, 2:48 pm

You should have a list of commits. If you give each commit a different name (hopefully a short description of the changes) then you can step back at any time to any level by selecting that commit and choosing Revert from the menu. (I use GitBox, but it’s probably similar/same in the “official” GitHub app.)

What happens when you revert is quite magical. All of the files in the repo are transported back to the point they were in when you made that commit, but the changes you have made since then are also preserved. If you go ahead of that commit (branching, in other words) you can still get back to where you were at your last commit in the list.

Walter

On Oct 5, 2013, at 10:07 AM, Thomas Kimmich wrote:

Oh gosh yeahh - I haven’t figured out this yet. The GitApp seems to keep just the latest save but not a “list of history” to step back in file-history. Hmmm - I have to mind about this.

Freeway user since 1997

http://www.walterdavisstudio.com

Todd

5 Oct 2013, 4:15 pm

Hi Thomas,

I’m glad you’re making progress.

I too use the GitHub app for tracking public GitHub repos (I have a couple from Walter I believe). Bitbucket’s free app offers a similar level control.

If/when it comes time to clone your GitHub or Bitbucket repo on your own remote server I don’t think you’ll be able to avoid using the Terminal. I can’t see any other way of doing it. The good news is it’s really quite easy.

Todd http://xiiro.com

I use GitHub and its own native app (no terminal required and nice looking

Back to Top

Todd

5 Oct 2013, 7:26 pm

Hi Thomas,

Great point about the upload details! I completely forgot about that one.

As for the list of commits they’re in there, as Walter said.

Going further, I would suggest getting in the habit of writing useful and thorough commit messages as it will be of great benefit to not only yourself but others if you start collaborating. Here’s a couple of many good suggestions for writing a better message,

http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history/ http://robots.thoughtbot.com/post/48933156625/5-useful-tips-for-a-better-commit-message.

Todd http://xiiro.com

MY FIRST BIGGER TROUBLE:

Committing a FW-file has the caveat of the “upload-details” which are naturally transported with the file. So I have to make sure to remove them before commit or to update it via FTP client and never fill them in (unwanted) as it is a live-project naturally.

THE MULTIPLE UNDOS (the main idea of this thread)

Oh gosh yeahh - I haven’t figured out this yet. The GitApp seems to keep just the latest save but not a “list of history” to step back in file-history. Hmmm - I have to mind about this.