There is an OS X installation of Subversion from a .dmg here:

http://metissian.com/projects/macosx/subversion/

Jenny

____________________________________

Jenny Harrison University of California, Berkeley 851 Evans Hall Berkeley CA 94720-3270 Tele: 510-642-9666 Fax: 510-642-5270 Email: harrison@math.berkeley.edu Web: http://math.berkeley.edu/~harrison/

On Mar 29, 2007, at 7:44 AM, Steve Lianoglou wrote:

Apple has a handy page on it.

http://developer.apple.com/tools/subversionxcode.html

Although there's a bit of realestate on that page devoted to installing apache/webdav/svn from source, I'd recommend installing the trio via macports.

The rest of the article is till handy though.

There is always, of course, the online book: http://svnbook.red-bean.com/

It's big, but it most assuredly will have all that you need.

-steve

On Mar 29, 2007, at 10:19 AM, Ethan H. Darling wrote:

...

Everyone/Anyone,

I'm new to Textmate (and just about everything else), and I just finished reading the Textmate book (some sections got a thorough once-twice-thrice-over). Very good book, now I'm hooked on Textmate.

I'm just an amateur web developer looking to increase my skill and knowledge. Textmate has been a great companion as It allows me to get out of Dreamweaver and into the code, but I find that I have lost some of the "project management" features of Dreamweaver. ie, being able to transparently upload completed development files from within the application. (Sure I can still get it done with Transmit, but it is clunky.) I searched the textmate discussions and wiki and came away with the conclusion that SVN is the answer. Problem is I know nothing about SVN... or where to start.

So, my question is... "What is SVN, can I really use it to manage a production website, and what is the best place, resource, book to get information on how to install, configure, and use it?" Sounds dumb right. Well we all have to start somewhere.

(I googled it and found more information than I can shake-a-stick at. So I thought that I would ask a smaller community that may better understand my situation and give a little more intelligent mac-oriented feedback.)

Thanks,

Ethan

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

On Mar 29, 2007, at 12:09 PM, Florian Gilcher wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi Jenny,

This page does only offer installer builds up to version 1.3 Stable. The current version of SVN is 1.4.3. It is advisable to use it because of this [quote from the release Page]:

So are there any binaries for 1.4 available anywhere, for those of us that don't want for one reason or another to use MacPorts / compile from source?

I wonder what happens with the bundle repository. I am actually still on 1.2.3 and can access it just fine, which means, if I understood the note correctly, that it is not 1.4. On the other hand this also means that any of the 100> committers would have to also use older clients, otherwise one of them would have changed the repository. Or am I misunderstanding something?

Haris Skiadas Department of Mathematics and Computer Science Hanover College

---

Working Copy and Repository Format Changes

Due to certain improvements and bugfixes made to the working copy library, the version number of the working copy format has been incremented. This means that Subversion clients earlier than 1.4 will not be able to work with working copies produced by Subversion 1.4. Similarly, the repository format has changed as well, meaning that pre-1.4 Subversion tools that normally access a repository directly (e.g. svnserve, mod_dav_svn, svnadmin) won't be able to read a repository originally created by Subversion 1.4.

WARNING: if a Subversion 1.4 client encounters a pre-1.4 working copy, it will automatically upgrade the working copy format as soon as it touches it, making it unreadable by older Subversion clients. If you are using several versions of Subversion on your machine, you need to be careful about which version you use in which working copy, to avoid accidentally upgrading the working copy format. This "auto upgrade" feature, however, does not occur with the new repository format.

---

To avoid any problems with this behaviour, new Users should always use at least 1.4.

Greetings Florian

Hi,

On 29.03.2007, at 18:15, Charilaos Skiadas wrote:

I wonder what happens with the bundle repository. I am actually still on 1.2.3 and can access it just fine, which means, if I understood the note correctly, that it is not 1.4. On the other hand this also means that any of the 100> committers would have to also use older clients, otherwise one of them would have changed the repository. Or am I misunderstanding something?

Yes you do. The svn client tool isn't one of the tools accessing the repistory directly.

svn itself only affects the locally checked out working copy. So if you upgrade your installation, you won't be able to downgrade any more.

Likewise, if someone on the server upgrades svn there, he or she won't be able to downgrade again once any tools accessing the repository directly (the DAV_SVN-module, svnserve or svnadmin) has touched the repository.

But checking out and commiting are operations your client does without directly accessing the repository on the server. That access flows via the apache-module or the svnserve binary.

Philip

On Mar 29, 2007, at 3:50 PM, James Edward Gray II wrote:

On Mar 29, 2007, at 2:32 PM, Rob McBroom wrote:

...

Most of the changes you make are small and stupid and not worth committing.

I strongly disagree with that.

OK, maybe I shouldn't have used such a broad statement. But even if it's "very few" instead of "most", what I said still applies.

The more you get into version control, the more you learn that those smaller changes are exactly what you want. You want to get it down to where each commit does just one thing, whether that's adding a new feature, fixing a bug, or just some copyediting.

Sure, and that's how I try to use it. But I wouldn't want to have to commit things just to get them over to a web server. If I did, there would be all kinds of commits with comments like "forgot a semicolon at the end of this line" or ten commits in a row saying things like "tweaking the spacing above and below H2 tags". Adjusting the spacing around a tag or setting something's color is a single "change" that only needs to be committed once in my opinion, but it might have involved dozens of trail-and-error updates to the file on disk.

Bottom line: Subversion is great for version control and crappy for "file transfer" or "remote editing", which is what the original question was about. Using it for other purposes would be a perversion of Subversion. :)

On an unrelated note, I'm going through the book now and have picked up a lot of good stuff.

--- Rob McBroom http://www.skurfer.com/ I didn't "switch" to Apple... my OS did.

On Mar 29, 2007, at 3:44 PM, s.ross wrote:

Are you committing things to SVN, copying to a Web server, and *only then* discovering a missing semicolon? Many developers use a process like this:

• checkout
• modify

- update

• test
• checkin
• prop

If you do the "test" part, the "ok, crap I forgot the semicolon" comments won't crop up as much.

Exactly. That's what I was trying to express as well.

James Edward Gray II

On 2007/03/29, at 22:27, Rob McBroom wrote:

Yes, this is exactly the process I follow. The issue here is that the "test" part can't happen until the files on the web server have been updated. Ergo, Subversion is not the right way to update those files because that would put "checkin" before "test".

To be more explicit, I keep the working copy on the web server rather than on my local machine and use some kind of remote filesystem to access it. I don't generally have local copies of any of these files. Perhaps that will clear up some confusion.

Why don't you use rsync or scp for synchronization with your web server? Check-out, modify, sync, test, modify, sync, test, check-in. Then on production web server you just want to update.

On Mar 29, 2007, at 4:38 PM, Charilaos Skiadas wrote:

...

2. I would think that it is particularly important that you have a

subversion system exactly when you do web stuff, where you need to check things on the actual server often. With a subversion system, you can update the server after you've committed the changes, and then if there are problems simply revert to the previous, known-to- be-working, version until you've worked out what went wrong.

OK, but whether I commit my new crappy changes or not, the old "known good" version was previously committed and I can therefore revert to it, so I'm not sure what you're getting at. When I think changes are good, I commit them. If subsequent changes were a horrible mistake, I can revert. If I committed every single change, as you seem to be suggesting, then I could revert to previous good versions and previous bad versions, but why would I ever want to do the latter?

My personal opinion: just commit things that actually *work*. Never, but really, never commit undone things or things that fail compiling or stuff like that. If you are using Perl, first of all check if it don't have syntax errors :-D

-- Igor Sutton igor.sutton@gmail.com

My 0.2 to this discussion (or "Some things I learnt working with talented people" :)

# Use a staging server.

If you can afford the exact same hardware and software, go for it. It will pay off in no time. If you can't afford even an "as similar as possible" server, go for Parallels. But never *ever* test on a live server.

# Use an automated, one-click deployment tool.

Cal Henderson, in his book "Building Scalable Web Sites", describes the system they use at Flickr.com. You'd be *really* impressed to see how their tool looks like (talk about simplicity :)

If building a custom tool looks like too much hassle, take a look at Capistrano[1]. You'll be glad you invested some time learning how to use it the first time you deploy a faulty application to a group of servers and can revert to the previous version in seconds.

# Subversion is your friend. Get to know it.

The amount of things Subversion can do is amazing. Take time to learn to master it.

Just a tidbit: did you know you can export your working copy to another location without checking in your changes?[2] This has helped me countless times when I want to test changes on a remote server before checking in to the repository.

# Post-commit hooks in Subversion are *powerfull*

Yet nobody seems to use them to their full potential. Some ideas on what you can do with them:

- Validate your HTML before checking it in. If it does not validate, don't add it to the repo. - Compress your JavaScript, keeping a "readable" version of the file. - Update your Basecamp with commit messages. - Auto-deploy on commit. - Run tests on commit (continuous integration[3])

# Use branches.

Branching is "cheap" in Subversion. If you want to "play" with code, create a branch. Merge only known-working changes.

# Don't be afraid of trivial commits.

100 trivial commits ("Added a comma", "Fixed typo"...) are better than 1 big (and potentially problematic) commit. Version control should be a part of your workflow, not the end of it :)

Commits are free :)

I guess what I'm trying to say is "know your tools". I couldn't live without version control right now, and I am a *designer* :) so if you code for a living you should really invest some time mastering Subversion.

And one last thought: if you think version control sucks, you are lacking information. Somebody once said: "If you explain it well enough, everyone loves version control". I can't remember the quote's source, but it is spot on ;)

[1] http://manuals.rubyonrails.com/read/book/17 [2] http://svnbook.red-bean.com/en/1.1/re10.html [3] http://en.wikipedia.org/wiki/Continuous_Integration

-- Ale Muñoz http://sofanaranja.com http://bomberstudios.com

On Mar 29, 2007, at 3:50 PM, James Edward Gray II wrote:

On Mar 29, 2007, at 2:32 PM, Rob McBroom wrote:

...

Most of the changes you make are small and stupid and not worth committing.

I strongly disagree with that.

Subversion is a tool for working with changes, much like Address Book is a tool for working with addresses. It has numerous operations for those changes including reporting on what was changed, by who, when, and the reason they gave for the change. Of course, it can only help you with what it knows about, just like your Address Book.

The more you get into version control, the more you learn that those smaller changes are exactly what you want. You want to get it down to where each commit does just one thing, whether that's adding a new feature, fixing a bug, or just some copyediting. Subversion then becomes even more powerful because you can work with these changes individually.

Let me add a couple of things to all this: 1) Every svn commit comes with four key pieces of information: WHEN it happened, WHO did it, a DESCRIPTION of what the commit is about and WHAT has changed. You can then search for all this information. In the context of a project involving more than one person, all these are absolutely critical things, especially if the members in the team change. Case in point is all the bundles in TM. We can actually search in the repository to find who added a new command or changed a line in the code, and what their rationale behind it was. (This is btw why it is very important that the commit messages describe the situation of the change and why it happened, instead of the change itself) However, even in the context of a single person, it is a great source of information, especially when you get back to a project you were working on 2 years ago or so. It's the same reason we add comments to source code, because the actual code does not reveal much about the *context* in which it was written and the considerations that were going on through the developer's mind at the moment.

You can also determine, within a particular file, exactly who was the last person to change each individual line and when.

2) I would think that it is particularly important that you have a subversion system exactly when you do web stuff, where you need to check things on the actual server often. With a subversion system, you can update the server after you've committed the changes, and then if there are problems simply revert to the previous, known-to-be- working, version until you've worked out what went wrong. Even better, you have the production server and a development server. So after you commit your changes, you update the development server and test there, and if things work out then you also update the production server. The update command in this context would be a simple "svn up" running in the servers, regardless of what changes you've made, instead of a bunch of scp/rsync's. You can just turn it into a textmate command and activate it with the click of a button.

On the other hand, if you manually copy your changes to the server and then it turns out you have made a mistake and this version is not workable, how do you revert to the previous version? You'll have to figure out exactly what you changed and change it back. That would seem terribly inefficient to me, when a simple "svn revert" would do.

I am however not a web developer, so perhaps there is something I misunderstand there, otherwise I really don't see how anyone could work on a big web project without a versioning system. A versioning system provides a complete journal of what happened when and why, things that can be invaluable. I've actually started using it for math papers as well (well, my thesis actually. But I am thinking it could be a really nice way to collaborate, though a paper has somewhat different problems not really solved by a versioning system. Anyway, I digress ;) )

James Edward Gray II

Haris Skiadas Department of Mathematics and Computer Science Hanover College

Before we continue down this road, let's be clear about what Rob is suggesting, because I was also mislead in my original responses by not reading his post carefully. Rob is not suggesting not to have version control. In fact, he already has it in all his servers. What he is saying is, what are the advantages of 1 over 2, where 1 and 2 are:

1) Having two checkouts of the repository, one local and one on the web server. Then making changes to the local version, committing and then updating the server side. 2) Having only a checkout of the repository on the web server, and remotely editing that checkout. Then testing, and only committing the changes if things work out. So he can still revert his changes.

So I think some of our points remain valid, but let's be clear about the issue. The issue is not version control or no version control, the issue is local checkout and not directly editing on the web server, versus direct editing on the web server.

Haris Skiadas Department of Mathematics and Computer Science Hanover College

On Mar 29, 2007, at 10:35 PM, Jacob Rus wrote:

Rob McBroom wrote:

...

I deal with several web sites and I use subversion to manage them. It's great at what it does, but… In my opinion, it's completely the wrong tool for the "transfer these updated files to the web server" part of the process, which I think is what you're after. I still edit all web site files remotely using Cyberduck (same clunky workflow as Transmit), Samba, DAV, SSHFS, etc.

And in my opinion, any process that emphasizes convenience over functionality so such a degree that it avoids a version control system in favor of making live changes on the server is completely the wrong process for the job. ;)

I hope I don't offend by asking: what do you expect someone to do when tweaking that file on the server, making those hundreds of small "stupid" changes, and something suddenly doesn't work? If he hasn't saved each intermediate step, with diffs and logs, how does he revert the problematic edit?

...

The problem, if you care, is this: If you have a copy of the files on your local machine and you want to make some updates then push them to a remote machine using Subversion, you have to "commit" your changes*. Most of the changes you make are small and stupid and not worth committing.

No, this is exactly the wrong idea. Most of the changes you make are small and stupid and you won't have any clue what they were or why you made them 2 days later when one of them turns out to have broken something. That's why every little change should be accompanied by some minimal commit message, and needs to let you see a diff, and roll back to the previous state.

...

I also prefer not to commit changes until after I've tested and know that I didn't break anything. Why keep track of mistakes, right?

The better question is why *not* keep track of all the steps. You keep track of the mistakes so you can more easily undo them. If you could immediately catch every error right at the point you make it, that would be one thing, but bugs can be very subtle and hard to isolate.

...

But of course, when dealing with web stuff, the changed files need to be on the server in many cases in order to be tested, which if you're using subversion to "transfer" them, brings us back to committing files prematurely.

There is really no such thing as a premature commit. Commits are free!

...

Many people on this list continue to suggest Subversion as an answer in a situation like yours, so maybe I'm missing something. If so, I'd love to hear what it is.

Yes, what you're missing is that the process that you are suggesting is very fragile and failure-prone. Small changes messing things up cause major headaches for everyone not using version control, and that's especially true if development is done on the server directly. I'm not sure that Subversion is necessarily the best answer--there are many nice version control systems.

But for any project bigger than 4-5 files, there is no excuse not to use some version control system, IMO. The little bit of inconvenience pays for itself many times over, as the developer stops worrying so much about breaking things, and can freely commit changes, secure in the knowledge that a known good state is only a quick revert away.

It is only the existing culture that keeps web designers from using version control systems. Hopefully this culture will change, because it wastes huge amounts of time for the developers involved, when they have to use guessing and fiddling as a recovery mechanism after breaking stuff.

-Jacob

I was that poster -- or at least one of them -- and I stand by that recommendation. Broken builds are simply not acceptable in a team environment where everyone needs passing tests to move ahead with their work. That's what branch and merge are all about. If you want to dork around with the code and check in changes that break the build, create a temporary working branch and do all of that there.

My rule of thumb is never make a checkin to trunk that will break a build.

Even if you are not running continuous integration or are a single- person shop, branching is still a good habit to get into because you may need to expand your team size at some point and then continuous integration will greatly speed up your development process.

Quoting from the Agile Manifesto[1]

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

To deliver working software frequently, you have to keep the software working. Right?

[1] http://www.agilemanifesto.org/principles.html

On Mar 30, 2007, at 11:52 AM, shin kurokawa wrote:

BTW, to another poster recommending no commits until something is verified to work ------ That's asking for trouble. Even if unverified, you should commit regularly... just make sure to log useful information. Your repo will not inflate much for minute changes. Again, YMMV.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Assuming most of you read the previous mails, i will skip citations ;).

A point that is totally ignored is that the size of the project matters. I worked on several small to big-sized projects with svn. With small projects, it is possible to have development and production on trunk and skip the hassle of branching/merging. On medium sized, it is advisable to have every bigger enhancement happening in a branch, while still having the live server working on trunk. The solution for our biggest projects was to use tags for live versions. (Tags are as cheap in svn) This ensures that no accidential updates happen. Updates on a live server are done by 'svn switch'. Usually, there is a beta server set up using the live database where tags a tested in between.

The point of 'only working things on trunk': sure, you should try not to commit totally broken code. But things that are not finished or contain minor bugs that annoy but don't break are okay - it is the active development branch after all. If you trust your ongoing development to go all well, you can use it as _the_ branch, but thats not always the best way. In an environment with multiple programmers, commiting everything is live-saving. 'Hey, xyz is ill today, do you have access to his working copy? This stuff has to be done today!' is a problem that does not need to be occur.

Greetings Florian

I thought I'd chip in to this conversation and offer my two cents..

I'm the lead developer for a new startup site, and we have about 5 people accross the globe working on the same 45,000 lines of php code (that's excluding libraries, javascript, css and html)... I've set up Subversion/Trac/Buildbot to manage everything, and it's working great...

I've set up a main trunk on which all the developers are working on, committing their code updates, etc. Because multiple people can be working on the same module at once and they use the repository to send updates back and forth, there's no single revision that can qualify for the production server. So what I do is use the svn branch capabilities, creating a 'branch' for each major version of the site. This involves copying the entire trunk to a new branch, collecting 'stable' revision numbers for each of the modules, and reverting the new branch to those revisions. Then I switch the sandbox on the production server to this new branch. If anything goes wrong, I can easily switch back to the previous branch which was working fine.

For major updates, I have a secondary 'beta' sandbox which runs on the same db, so I can switch that first, test it, and then switch the production server...

I demand that my developers do a commit at least once a day, even if they have unfinished code, all they have to do is put a note in the log. As Jacob said, commits are free. Plus, by using branches, I can push a 'small and stupid change' on the branch without updating anything else. If I want to change something on the server directly, again, I can commit that change on the branch (I just have to remember to mirror that change on the trunk, because it will be lost when I switch to a new version).

As for 'changing files directly on the server', I'm 100% against that. If you really want to monitor the changes as they happen (which you should), set up a local environment, or dedicate a subdomain of your site for development (and have the 'development' run on a different database). If you don't have the capability of doing that, then you're most likely running a fairly standard setup which you can easily replicate on a local machine, so again, just have a webserver running on localhost and check all your modifications there. Don't let that prevent you from committing early and often though, you don't have to update to the live server till you're done :)

As for bigger projects, using a tool like Trac and Buildbot is definitely indispensable. One of my developers insists on committing code with basic syntax errors in them, so atm I'm working on having buildbot run php -l (lint check) on every committed file, and email me and the developer if there are syntax errors in the committed code :) All of this integrates VERY well with subversion. (btw any help with buildbot is appreciated, though I know this is not a topic for this thread... shot in the dark. If you feel like you want to help a sysadmin-by-force out, i'd greatly appreciate it ;)

-2c

(btw I'm sort of learning as I go here, so if anyone has any suggestions, I'd be more than happy to hear them :)

PS. TextMate rocks. If this thing I'm working on takes off (I'll know in a year), I'll probably spend a year or so working for free on tools I like, and TM bundles are on the top of my list

Constantinos

On Mar 30, 2007, at 9:49 PM, Ethan H. Darling wrote:

Jacob,

I strongly agree with your statement about web designers/developers not embracing version control. That is why I'm trying to be as counter-culture as possible. I just started a degree program for Website Development and Management and I'm shocked to learn that at no point in time will the curriculum topically address version control. So, I'm on my own and that is what triggered this thread. Your observation has really encouraged me to continue learning about SVN and integrate it into my professional toolbox.

Thanks,

Ethan

On Mar 29, 2007, at 10:35 PM, Jacob Rus wrote:

...

Rob McBroom wrote:

...

I deal with several web sites and I use subversion to manage them. It's great at what it does, but… In my opinion, it's completely the wrong tool for the "transfer these updated files to the web server" part of the process, which I think is what you're after. I still edit all web site files remotely using Cyberduck (same clunky workflow as Transmit), Samba, DAV, SSHFS, etc.

And in my opinion, any process that emphasizes convenience over functionality so such a degree that it avoids a version control system in favor of making live changes on the server is completely the wrong process for the job. ;)

I hope I don't offend by asking: what do you expect someone to do when tweaking that file on the server, making those hundreds of small "stupid" changes, and something suddenly doesn't work? If he hasn't saved each intermediate step, with diffs and logs, how does he revert the problematic edit?

...

The problem, if you care, is this: If you have a copy of the files on your local machine and you want to make some updates then push them to a remote machine using Subversion, you have to "commit" your changes*. Most of the changes you make are small and stupid and not worth committing.

No, this is exactly the wrong idea. Most of the changes you make are small and stupid and you won't have any clue what they were or why you made them 2 days later when one of them turns out to have broken something. That's why every little change should be accompanied by some minimal commit message, and needs to let you see a diff, and roll back to the previous state.

...

I also prefer not to commit changes until after I've tested and know that I didn't break anything. Why keep track of mistakes, right?

The better question is why *not* keep track of all the steps. You keep track of the mistakes so you can more easily undo them. If you could immediately catch every error right at the point you make it, that would be one thing, but bugs can be very subtle and hard to isolate.

...

But of course, when dealing with web stuff, the changed files need to be on the server in many cases in order to be tested, which if you're using subversion to "transfer" them, brings us back to committing files prematurely.

There is really no such thing as a premature commit. Commits are free!

...

Many people on this list continue to suggest Subversion as an answer in a situation like yours, so maybe I'm missing something. If so, I'd love to hear what it is.

Yes, what you're missing is that the process that you are suggesting is very fragile and failure-prone. Small changes messing things up cause major headaches for everyone not using version control, and that's especially true if development is done on the server directly. I'm not sure that Subversion is necessarily the best answer--there are many nice version control systems.

But for any project bigger than 4-5 files, there is no excuse not to use some version control system, IMO. The little bit of inconvenience pays for itself many times over, as the developer stops worrying so much about breaking things, and can freely commit changes, secure in the knowledge that a known good state is only a quick revert away.

It is only the existing culture that keeps web designers from using version control systems. Hopefully this culture will change, because it wastes huge amounts of time for the developers involved, when they have to use guessing and fiddling as a recovery mechanism after breaking stuff.

-Jacob

---

_ For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

On 30. Mar 2007, at 18:52, Constantinos Neophytou ♎ wrote:

[...] As for 'changing files directly on the server', I'm 100% against that. If you really want to monitor the changes as they happen (which you should), set up a local environment [...]

While a local testing environment definitely has advantages such as being able to work offline, having zero network delays while testing, etc. I also find it is a good exercise in how many dependencies you have.

I.e. if setting up a local testing environment is a pain because you have lots of dependencies and no good view of them, or you require all sorts of setup and whatnot, well, then you probably should migrate to a simpler architecture, it might just be that one day you want to move your site from Linux to BSD, from one hosting service to another, or maybe you want to wrap up your code and sell it, start it on another server, etc.

On Apr 2, 2007, at 11:15 AM, Rob McBroom wrote:

As for making changes on "the server" being a bad idea, we don't make changes on *the* server. We make changes on *a* server. The development server, to be specific. Nothing wrong with that in my opinion.

---

Rob McBroom

I have worked like that in the past. http://subtlegradient.com/articles/2007/03/30/web-development- environment-and-workflow

There is nothing wrong with having an environment that requires uploading files to a dev/test server before you can test them. Other than being really tedious and annoying that is ;)

Hopefully TextMate 2.0 will allow for plugins and bundle commands that can make integrating FTP/SCP a lot easier.

I've written a command that helps me formulate good SCP commands. I then check them over and execute them manually from the terminal. You can never be too careful with your production server :D

thomas Aylott — subtleGradient — CrazyEgg — sixteenColors

On Apr 2, 2007, at 1:18 PM, Rob McBroom wrote:

On Apr 2, 2007, at 11:32 AM, Thomas Aylott (subtleGradient) wrote:

...

There is nothing wrong with having an environment that requires uploading files to a dev/test server before you can test them. Other than being really tedious and annoying that is ;)

Yes, and this seemingly immortal thread has brought the annoyance back to the front of my mind and forced me to think about it further.

I just had an idea, but it seems too obvious, so I wonder if it's been tried already or if I'm overlooking something.

1. Create a local copy of things
2. Create a project from the local copy
3. Define a project-specific variable like `WHERE_I_CAME_FROM`

that contains a remote path that `rsync` understands, like `webserver.foo.com:/blah/htdocs` 4. Create a command that runs

    rsync $TM_PROJECT_DIRECTORY $WHERE_I_CAME_FROM

And of course you'd want to add some options to `rsync` and perhaps some additional smarts, but could this work? I fully intend to experiment with this, so if no one chimes in with "been there, done that", I'll share my results.

---

Rob McBroom http://www.skurfer.com/ I didn't "switch" to Apple... my OS did.

That is almost exactly what I've done before. Except that I didn't know about rsync back then and just used the Transmit bundles "mirror this file" (or whatever it's called) command.

thomas Aylott — subtleGradient — CrazyEgg — sixteenColors

On Mar 29, 2007, at 10:35 PM, Jacob Rus wrote:

And in my opinion, any process that emphasizes convenience over functionality so such a degree that it avoids a version control system in favor of making live changes on the server is completely the wrong process for the job. ;)

Not committing to the repository every time you hit ⌘S is not the same as avoiding revision control. There's a balance. And no one ever said you should do this on a public/production server. In fact, I'll state the obvious and say that you should not. But I'm going to make changes on *some* server, because to change files on my local machine would be meaningless. The files don't "do" anything for me unless they're in the right context, which is often a specific web server.

On Mar 30, 2007, at 7:42 AM, Charilaos Skiadas wrote:

Before we continue down this road, let's be clear about what Rob is suggesting, because I was also mislead in my original responses by not reading his post carefully. Rob is not suggesting not to have version control. In fact, he already has it in all his servers.

Yes, I think by now the original poster should be thoroughly convinced that revision control = good. A lot of text in this thread has been dedicated to selling it or even defending it, which I don't understand since no one ever said it was bad. I'm going to try something crazy and actually answer his question.

The issue at hand is one we're all familiar with: TextMate is awesome. Because it's awesome, we want to use it for everything, but a significant portion of "everything" is on a remote machine. So, how do you work with remote files using an editor that's thoroughly local?

For someone who's used to Dreamweaver's "Site" features and thinks the workflow associated with using Transmit is clunky (rightly so), telling them to use Subversion *for the specific purpose of pushing local changes to the server* is going to go over like a turd in a punch bowl. I promise. (I'm not saying revision control shouldn't be used at all.) So, what can be done?

## Use Cyberduck or Transmit

Pros:

* Uses protocols you probably have in place already * Lets you see remote files and double-click to edit * Lets you work with a local copy and transparently uploads changes

Cons:

* Doesn't allow for use of TextMate's wonderful "Project" features

## Make the remote files appear local (DAV, AFP, Samba, NFS, SSHFS, etc.)

Pros:

* Lets you manipulate files using a familiar interface * Allows you to use TextMate's project window

Cons:

* You might need to set up one of these protocols which is not trivial and comes with various risks and headaches * Remote filesystems range from annoyingly slow to unacceptably slow

Other considerations:

* Samba, for me, has proven to be the fastest and it's quite mature at this point. The problem is, if you use Subversion (which holy crap, I do!, believe it or not), there are a lot of things you can't do to your working copy when it's on an SMB filesystem, so you're stuck with connecting via SSH to do `svn` commands instead of doing them from TextMate's project window. Gay. * DAV allows you to do all of your `svn` operations locally (which means it can be done via the Subversion bundle in TextMate), but it is so slow that it makes TextMate projects unusable. * FUSE with SSHFS is almost as slow as DAV, doesn't allow you to do `svn` stuff, and has demonstrated glitches that prevent me from trusting it for important work. It's still very new though, so things will likely improve. * I haven't tried NFS or AFP because I'd never be able to convince our system guys to set it up, so I can't comment on their strengths and weaknesses.

## Work with a synchronized local copy (via rsync)

Pros:

* Uses protocols you probably have in place already * Allows you to use TextMate's project window * The local filesystem is fast

Cons:

* Synching is an extra step that can add up if it's done frequently * I've never tried to use rsync on a Subversion working copy. Maybe it works great, but the idea makes me uneasy.

## Subversion or some other revision control

* Use it! But use it to track your changes, not to transfer files.

--- Rob McBroom http://www.skurfer.com/ I didn't "switch" to Apple... my OS did.