On 11-03-23 05:37 PM, Platonides wrote:
Daniel Friesen wrote:
((And before anyone says anything, there's no way I'm putting private keys on servers operated by a 3rd party, or doing development of things on my local machine -- reconfiguring apache and trying to get packaged apache and mysql to NOT start up on my laptop except when wanted is a pain))
On which OS?
Ubuntu. It likes to restore rc.d entries when you upgrade. The /etc/defaults files don't have on/off toggles. And iirc mysql is now a upstart. I used to do development locally but I got tired of playing with /etc/hosts and editing apache config files when I switched projects. In any case, I like using remote servers. Less local config, and I have an actual working link when I need to show something to someone else. .gvfs makes working with remote files as seamless as working with local files. It also lets me work nicely on prototypes of live sites in the proper environment.
In svn this is a workflow like so: server$ # Edit some code server$ svn up # make sure things are up to date desktop$ svn up # make sure things are up to date desktop$ svn diff | pager # look at the changes that will be pulled desktop$ ssh server "cd /path/to/code; svn diff" | patch -p0 # abuse ssh, svn diff, and patch to pipe changes to the local copy desktop$ scp server:/path/to/code/newfile . # if I added a new file, I need to randomly copy it desktop$ svn diff | pager # take a look at the changes to double check everything is in place desktop$ svn revert [...] # I often work with a dirty working copy with multiple projects mixed together, so I have to revert some unrelated changes or manually list files in svn commit desktop$ # sometimes those changes have two different projects in one file and I have to commit only part of it desktop$ svn diff somefile.php> tmp.patch # I found the easiest fix is putting the changes into a patch desktop$ svn revert somefile.php # erasing all local changes in the file desktop$ nano tmp.patch # editing out the unrelated code changes from the patchfile desktop$ patch -p0< tmp.patch # and re-applying the changes desktop$ rm tmp.patch desktop$ svn commit [...] # And finally I can commit server$ svn up # update the server, things get /fun/ if you try to pull patches a second time
;) guess what, this is an explanation for half the reason why I commit small changes to svn without testing them.
Seems easier to keep home at the same version as the server, rsync from server to home, and then update before committing.
Perhaps. But I expect something like that would also dirty up my clean working copy with config files and other junk that I would need to make a long explicit list of. Being able to commit server side is still a git advantage, and so is being able to make easy partial commits without playing with things like patch. I can also turn some of my dirty code into commits on dangling branches that get re-integrated when I pick the project back up.
Here's another good case for extension-as-repository.
(...)
Extensions are as much used as-is in both trunk and stable. In other words, we use and develop the same version of an extension whether the phase3 around it is trunk or something like REL1_16. However we do not always develop every extension at once. If every extension is in the same repo we are forced to checkout every extension (...) and all of those extensions MUST be of the same branch. This means that if you have a REL1_15 phase3, and you want to use some extensions that try to be backwards compatible and others which have a trunk that breaks you are forced to use branched extensions for EVERY extension, and you forgo the features of the extensions that DO try to be compatible (I DO use both branched and trunk extensions on stable non-development). This is even worse when developing. If you are trying to develop extension compatibility for an old release everything MUST be trunk since you can't really develop in the release branch. As a result any other extension you are using that doesn't have 1.15 compatibility will end up causing unrelated fatal errors hampering your compatibility testing.
Good point.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]