05 Nov, 2008, quixadhal wrote in the 161st comment:
Votes: 0
What? Did you say something Runter?
06 Nov, 2008, Avaeryn wrote in the 162nd comment:
Votes: 0
DavidHaley said:
May I ask why SVN was chosen? Obviously I think it has its flaws, so I'm curious why it was chosen. If the answer is "it's what we know" that's cool too, I'm just wondering if there was any technical factor in the decision.


SVN was what we had access to. Simple enough to answer that question. I should think it needs no more explanation. :cool:
06 Nov, 2008, Avaeryn wrote in the 163rd comment:
Votes: 0
quixadhal said:
What? Did you say something Runter?


Hurry Runter! Get some smelling salts! He's going out of it again :unclesam:

You know, quix does tend to forget things, but it really is in the most light-hearted way possible. If that's even possible. Gawd…words, euphemisms, etc. Plus since he's so old, he looks kind of cute and cuddly in his town crier costume. I have to say it's endearing, really.
06 Nov, 2008, David Haley wrote in the 164th comment:
Votes: 0
Getting access to open-source software on a Linux box is such a trivial problem to solve as to not really be a problem… :tongue:
06 Nov, 2008, Runter wrote in the 165th comment:
Votes: 0
That's true…but a man of his age. I would expect him to be the mayor by now. :)
06 Nov, 2008, Runter wrote in the 166th comment:
Votes: 0
*hopes he didn't break anything*

*made his first commit to his branch using svn*

I don't have a lot of experience with it yet. So if I'm doing something wrong please let me know.
06 Nov, 2008, quixadhal wrote in the 167th comment:
Votes: 0
Looks ok so far.

One of the nice/interesting/weird things about svn is, of course, that you don't HAVE to checkout the tree from the root, and likewise I'm pretty sure if you are in a subdir when you do a commit, it only puts changes to that tree into the new revision. The reason that's interesting is that if you only cared about your own branch, for example, you could stay down in there and only commit/update from it, and thus not download anyone else's changes. The reason that's weird is that anytime ANY file in the entire repository is updated, the revision number goes up.

So, you and I could both make changes to just one file in totally seperate branches, and once we've both committed the changes, we'd go from revision 36 to 38. :)

Also, there's a black magic command you might want for your branch. I *think* a copy operation preserves it, but if/when you add new files, you may want to use it.

svn propset svn:keywords "Id" filename.c filename.h

CVS had keywords always active, so if you had a binary that happened to have $Id$ embedded in it, it would break. SVN only does that kind of expansion if you tell it to, so on all the C source and header files, I did that command so the Id tags get fleshed out on update/commit. I also did it for the Makefile, but not for any of the docs or other stuff.

The version number in the Id tag is the last revision that file changed, not the latest global revision number. Just in case it's confusing. :)

My first official act as Mayor-elect shall be the redirection of all city tax revenue into a project to beerify the public water purification system. From now on, every household will have cold running beer instead of water. I know some people will find washing their clothing in beer, or showering in beer, to be a bit strange at first, but the savings in not needing to go to the bar, and not having to buy other expensive medications, should more than justify the transition.

What was I saying? Hmph…
06 Nov, 2008, Avaeryn wrote in the 168th comment:
Votes: 0
quixadhal said:
My first official act as Mayor-elect shall be the redirection of all city tax revenue into a project to beerify the public water purification system. From now on, every household will have cold running beer instead of water. I know some people will find washing their clothing in beer, or showering in beer, to be a bit strange at first, but the savings in not needing to go to the bar, and not having to buy other expensive medications, should more than justify the transition.


So instead of 40 acres and a mule, every household will have freely-running beer and a keg?
09 Nov, 2008, quixadhal wrote in the 169th comment:
Votes: 0
It looks like the fun part of using SVN is almost upon us!

Yes, that's right kids…. the MERGE command! *cheers with the crowd*

If you are ready for some entertainment, Runter is almost(?) done with his listification of his local branch. If the merge command works like I *THINK* it does, you specify two working copy directories and attempt to merge the changes in each of them to the copy you're sitting in (which should probably be one of those two). Then you get to handle all the conflicts that will show up, and finally do a checkin if it all works. :)

For added bonus fun, you can probably try it in either direction….

I expect this one to be ugly, since we've both walked all over the files, but it'll be a good test, no? I also plan to make sure I know the revision numbers right before I try it, just in case it tries to auto-commit or some such nonsense.

If all goes well, and I have enough alcohol to accomplish it, all of Runter's hard work will become part of Ice, and he can close his branch and re-open a new one to do more evil stuff. Of course, he might want to try merging the Ice changes into his as well… it might be a fun way to learn. :evil:
10 Nov, 2008, Runter wrote in the 170th comment:
Votes: 0
Hrm. I finally got 1.5.2 and did a merge into my working branch.

What a headache.

Maybe I'm doing something wrong but everywhere that you've changed something like

int i;

to

int i = 0;


it's making me go around that code and figure out (with a lot of duplicate code) what code goes where.

Also, it seems to have just discarded some code before the merge. A few lines of code I had changed just totally reverted to previous code. I've had to redefine some variables, and fix a lot of linking errors that I have no idea where they came from.

Like I said, maybe I'm just doing something wrong. But isn't this supposed to be pretty easy? The only thing that seems easy about it at this point is putting bugs in the code that weren't there before the merge.
10 Nov, 2008, David Haley wrote in the 171st comment:
Votes: 0
Merges are fairly easy to screw up if either end of the merge does something wrong. It also depends on how good the tool is. That said, svn is supposed to be pretty good at this.

The int i –> int i = 0 change should be trivial. It's possible that stuff was changed around it (even just whitespace). Whitespace is actually a very common pain point for stuff like this.

I've never actually used non-trivial svn merging. FWIW I've done pretty large merges using tools like bzr. But as I said svn is supposed to be good at this, so I'd be a little surprised if it couldn't handle merging back to a common ancestor. (Ya'all did use common ancestors and all that, right, and are merging two trees that were branched off of the same point etc.?)
10 Nov, 2008, Runter wrote in the 172nd comment:
Votes: 0
I don't know. I'm sure I just did something wrong with the merge.

I'm just trying to update my branch with any changes that have been made to the trunk I guess.

And yeah, I'm pretty sure a lot of it was whitespace changes that Quix has made to pretty much every line of code. *mutters*
10 Nov, 2008, David Haley wrote in the 173rd comment:
Votes: 0
If you branched, and then Quix did his whitespace stuff after your branch, then yes, you're probably in for a world of pain as you merge that stuff back because svn will think that things changed when really they didn't (modulo whitespace). That's one reason why as a company policy here for example we try to avoid changing whitespace even if it "should" be fixed, just because it can confuse version control if somebody else is working on code in the vicinity.
10 Nov, 2008, Runter wrote in the 174th comment:
Votes: 0
Alright, so after my first attempt I just took a break. I came back and tried the same thing and now svn isn't handling http URLs correctly. I'm assuming it has something to do with the module it uses to look that up.

So it worked before, but now it won't.

I went ahead and uninstalled svn and reinstalled it once again. So I rebooted and still nothing.

Anyone got any hints at why it might have just randomly stopped working?

I can't even svn update at this point.
10 Nov, 2008, David Haley wrote in the 175th comment:
Votes: 0
It could be a problem on the server end, unless you're not able to use svn with any HTTP URLs. That'd be the first thing I'd try.

Is it worth pasting the svn output when you try to update or is it completely unhelpful?
10 Nov, 2008, Runter wrote in the 176th comment:
Votes: 0
Yeah it wasn't working with any URL. but…
I figured out what was wrong. (I still don't know why it randomly stopped working. I never even logged out of the shell)

Long story short I had a subversion version that I had built from source that didn't have the URL module correctly built.

And for some reason it just randomly started using that installation of svn instead of the one it had been using earlier. So I got rid of that one and have it using the correct installation now.
10 Nov, 2008, David Haley wrote in the 177th comment:
Votes: 0
Oh… probably just a path or environment issue then.
10 Nov, 2008, quixadhal wrote in the 178th comment:
Votes: 0
Runter said:
Hrm. I finally got 1.5.2 and did a merge into my working branch.

Hooray!
Runter said:
int i;

to

int i = 0;


It really should be able to figure out THOSE kinds of changes itself, unless you also did changes right near those. Yes, one of the larger change sets I did was to make sure EVERY variable that I could find was initialized to a known value at declaration. It helps when debugging, since things are setup for you on entry to the function's frame, rather than after running a few lines of code.

Runter said:
But isn't this supposed to be pretty easy?


Nope, but it's easier than everyone working on their own code and then plopping tarballs down and saying "Ok, let's merge!". The point of allowing svn to merge is that it should be able to figure out non-conflicting changes itself (IE: If I change multi_hit() and you change one_hit(), and we have no overlap…. that's automatic).

It's also possible that your editor may have inserted tabs or changed whitespace itself. That's why I pushed to get indent in use, with an indent.pro file in the src directory, so if you run into those kinds of problems you can re-run code through indent before trying to merge. Again, normally I'd expect svn's diff to be able to figure that out… but… :)
11 Nov, 2008, David Haley wrote in the 179th comment:
Votes: 0
If you're going to worry about tabs vs. spaces, you should pick one and then enforce it with deadly force if necessary. No, seriously, mixed whitespace really confuses a lot of things.
11 Nov, 2008, quixadhal wrote in the 180th comment:
Votes: 0
I did pick one (spaces), hence the use of indent…. unfortunately, I can't force indent to run as a filter on commits, so I have to yell at people who use tabs and thus make me go run indent on their stuff again. :mad:
160.0/181