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