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]
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
