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]