After various Mac system and security updates found that ssh+svn would result in errors…
svnserve: Command not found. svn: Connection closed unexpectedly
Wishing those at Adobe writing about DreamWeaver’s wonderful subversion integration would not keep omitting Deletion. Perhaps it is because deletion is not implemented in any automated sense (link) in DreamWeaver’s subversion client and the only sensible way to manage deletions or indeed renames (which as far as subversion is concerned is delete old file and add new file) is to use a 3rd party client. In my opinion this is all the more reason to mention this in articles like that in December’s EDGE “A guide to Subversion integration in Adobe Dreamweaver CS4”. Failing to provide notes on file deletions and file renames is going to leave newbie subversion users in a bit of a mess, with old files hanging around, or being restored when not expected following a revert.
My earlier notes related: Dreamweaver CS4, Subversion and site Synchronize. Two cautions.
The following notes assume three file sets: A: the remote site; B: The local site; C: The repository.
We are linked to the repository using the SVN+SSH method I discussed yesterday.
In this particular site, I have a folder within which server-side code generates and deletes server-side text files and modifications to MS Access databases. It is therefore necessary to sync from the server to the local copy. This is done using the settings: Get newer files from remote, and delete local files not on remote server. As in the following dialogue.
However in my particular site my preview list of files appeared as follows. Can you spot what’s wrong?!
By linking your local site to a subversion repository, you make that local site folder a working copy. This creates a host of hidden files within your local site folder which are used to coordinate synchronisation with the repository. These files should only ever be touched by Subversion. Dreamweaver however has decided in its synchronisation process to check to see if each of these files are on the remote server. Of course they are not – nor ever should be. Dreamweaver has then listed them for deletion!
Important: DO NOT ALLOW ANY OF THESE FILES TO BE DELETED as part of this sync-down. Doing so will break your working copy and break your local site’s sync with the repository.
Of course in the preview list you can go through and set the files you wish not to be afftected to be skipped as I have in the following snapshot…
Clearly from the above Dreamweaver has not only given me a huge list to work through, but in doing so has wasted a whole load of time – the FTP commands for checking 900 files are quite time consuming.
I’m not sure why Dreamweaver is including .svn files in this particular synchronisation effort. I can think of no use-case where this would be desired. Dreamweaver is smart enough not to attempt to sync .svn files when updating to the remote server rather than from the remote server.Therefore I suspect this is an over-sight, and I have logged it as a bug via the Adobe Bug Report Form.
There is a quicker safer way to avoid .svn files being sync’d in this way, and that is to use cloaking. For each site at issue, right-click the site’s root folder and choose Cloaking > Settings…, then enable cloaking and add .svn to the file list…
Deleted site files, either deleted via a sync operation or direct deletion in the Files window, do not get committed to the repository on your next ‘check-in’. In fact so far I have not seen any way for Dreamweaver to inform the repository of deletions and I am currently relying on 3rd party tools to undertake the commit. In my case I use SCPlugin and commit the site folder, at which point it will list the deleted files as ‘missing’. Selecting those and hitting commit records them as deleted to the repository.
Maybe I’m missing something as this seems a major omission of basic functionality. It is quite dangerous for deletions not to get properly recorded to the repository, running the risk that the deleted files may be inadvertently restored to the local copy and eventually to the live site.
Update (4 November 2008):
Having found the documentation, it is clear that Dreamweaver’s subversion integration really does not extend to committing deletions to the repository. They need to be done either manually or through a 3rd party tool as I describe above. Pretty unfriendly for anyone new to subversion and quite different from the workflows used within dreamweavers for sunchronistion between local and remote sites for instance. Personally I think the documentation should explain this fact much far prominently as well as describing in more detail how manage deletion and renaming if connected to subversion.
I’ve been using subversion for a few years now. Initially used through subclipse within Eclipse/Flex Builder then later also used with Dreamweaver sites using tools such as svnX and scplugin along with the “Cloak SCM directories” command. In most cases to date, I have used the “file:///” protocol as this provides direct and efficient access to repositories which are available within the local system or local area network. I had been looking forward to subversion integration in Dreamweaver and when the CS4 public beta was released I had a bit of a moan about the absence of the file protocol. Despite my efforts in the beta’s forum and the Dreamweaver wish-list, it remains absent. So now to look to using a different protocol.
There is a helpful 3 part article on the Adobe site describing how to get started with dreamweaver CS4 and svn. In part 3, the author chooses to present how jump through the hoops to get Apache to serve and access a local repository over http. There are a number of reasons why this approach is not right for me:
By using svn+ssh, svnserve launches on demand (no need for a running daemon) and we have access to all the paths available to the ssh user logged in.
So, to get this going on Mac OS X 10.5…
Turn on ‘Remote Login’ in the ‘Sharing’ system preferences. Rather than using the default of allowing access for all users, I restricted access to only my user.
At this point you should be able to use sv+ssh urls from within terminal. e.g.
% svn info svn+ssh://[email protected]/Volumes/full/path/to/repository
However if you try to use the same connection in a tool such as svnX you are likely to get error : ssh_askpass: exec(/usr/libexec/ssh-askpass): No such file or directory
To get around this we really need to establish public key authentication, which also serves to avoid you having to use your user account’s name and password for the connection. Based upon this article on OpenSSH, I did the following:
% cd .ssh
% ssh-keygen -q -f id_rsa -t rsa
Update 16-Feb-2009: Since writing this and applying an number of mac system and security updates i today found that any attempt to ssh+svn would result in…svnserve: Command not found. svn: Connection closed unexpectedly [exit=1]command="/usr/bin/svnserve -t"
As this is my one and only public key, I simply uses the following line to copy the public key to a file called ‘authorized_keys’. However if you are dealing with more than one key, you should use the guaidance in the OpenSSH article to append the key to that file.
% cp id_rsa.pub authorized_keys
Once this has been done, attempting to use your svn+ssh url within svnX should now work. Note: you may get the error re-displayed, but it will dismiss to be replaced by a current view of the repository. Also the first time, you will be prompted for the password. Here you need to enter the passphrase you used when you created the rsa key. I chose for this to be remembered in my keychain to avoid having to retype it in future.
With this done, you are now ready to contemplate setting up Dreamweaver. You need to be aware that an subversion working copy knows the url to the repository from which it was checked out. If your existing DW local copies of sites are subversion working copies checked out like mine via the ‘file:///’ protocol, you need to migrate them to ‘svn+ssh://’ so:
(Update: 28/10/2008 here)
Having been chastised for using these ‘unknown acronyms’ in my comment on jd’s weblog, I thought it worth writing a brief entry describing what these acronyms stand for and how they may be of interest for those purchasing or upgrading Adobe software.
Essentially this is all to do with volume licensing as an alternative to purchasing products through the Adobe store or other 3rd party suppliers. Volume licensing sounds like it is aimed at large organisations purchasing site-license. However the Transaction Licensing Programme facilitates as little as a single product license. The way the scheme works is to provide a transaction discount should you purchase multiple products in a single transaction based upon a point value for each product. TLP purchases may be made through 3rd party suppliers, but also through Adobe directly as in my case. There is no published price list so you need to request a quote.
The key point of interest to me was the Upgrade Plan which allows licenses to be purchased over 24 month subscriptions. Essentially this means I effectively have already paid to cover my CS4 upgrade. This is the point I was trying to make on jd’s weblog. He acknowledges that trial versions of CS3 products not being available until mid November is a ‘Pain point’ and he provides some explanation including the phrase “The big shipping versions get released first.”. Well I’m a AOO TLP upgrade licensee who’s just been told I may have to wait until the ‘end of November’ for it to physically ship to me. If it is painful for ‘users’ who haven’t paid for the software yet, imagine the pain for those who have paid for the software, but may have to wait until the end of November.
So while the Upgrade Plan offers some value, fulfilment seems less than ideal especially given this Key benefit documented on the Adobe site: “Get timely notifications of new upgrades, so you can stay on top of new product releases.”.
This is now my latest bug-bear. For Adobe to see how the customer experience could be improved in this regard, they need only look back to the now discontinued Macromedia DEVNET Pro subscription, where serial numbers and downloadable installers were immediately available to subscribers from day one of a new product shipping.
If this was fixed, I could now be blogging about cool new stuff in CS4 rather than fuming over this and wondering if I would actually be better-off purchasing through conventional means.
Received my Adobe License Fulfilment email on 26th. Logged in and was able to request media for the upgrades, but at the time couldn’t see serial numbers or any way of downloading. However just checked again today, and the serials are there and I now have downloads in progress – and at a good bit-rate. So I’m feeling a lot happier now than when this post was originally published. While the process has not been entirely seamless, this time is far better than my previous experience with CS3 where I had to wait for physical media.
I’m not usually one for echoing release announcements. Herewith one minor exception. With the arrival of a number CS4 betas on labs I was please to see “Subversion integration” being a new feature of DreamWeaver CS4. After a history of making simple Zip snapshot backups, and more recently using subversion along with the “Cloak/Uncloak SCM directories” extention and client tools such as SvnX, and SCPlugin it will be interesting to see how well the integration has been done. Looking good from the description.
Update: Unfortunately looks like Subversion is only supported through a server in this release. I really need it to be able to use the “file:///” protocol to access repositories on my local system without having to set up a server. Here is my entry on the Dreamweaver Beta Forum, feel free to add to it if you have opinions one way or the other.
A busy few weeks starting tonight:
Not sure why they couldn’t have been ready when the product shipped? But they are there now.
Now I just need to persuade Adobe UK Licensing that my MVLP Studio 8, 24 month subscription sold to me when my DEVNET account expired does in-fact cover this upgrade to CS3 Web Standard. I’ve been playing email ping-pong with them over this for the past couple of weeks. Hopefully this will be resolved before my trial versions expire!