C2C SVN Changelog

[Thunderbrd]

I have only encountered having to merge a few times and yes they do let you compare. Most of the time the parts edited in a file do not overlap. So they merge nicely. its only the very rare times that there is conflict. I think this is mostly due to how open/transparent we are on who is doing what and we rarely have to step on each others toes.

Always update before commit.

What will happen if you've altered a file that someone else altered in the meantime is NOT a complete overwrite of everything you've done. It usually doesn't even cause you a problem unless its directly to the same PORTION of that file that changes were made.

More often than not it will harmlessly auto-merge the changes in so that when you do go to commit you don't overwrite everything they just did with a file that doesn't include their changes.

If there IS a direct conflict then it will let you know when you update that there are files in conflict. Right click on those conflicts and select the option to open up the onboard compare program with those files. The compare program is quite easy to use though it may take some playing around with to figure it out. I'm sure as a gamer you can quite easily figure out how to get it to do what you want it to but if you get reeeeeealy stuck let me know and I'll walk you through the stuff... it's just that it tends to be more complex to explain than it is to figure out.


That said, I did NOT update before my last commit because I knew there was a problem with one there and I knew that none of the files I had manipulated were altered since my last update. Additionally, I had THOUGHT there would be a way to surgically extract a particular update from the SVN stream but apparently I'm wrong so I'll recompile a new dll here since I've already moved on from that one and re-commit tonight.

 

[strategyonly]

I have only encountered having to merge a few times and yes they do let you compare. Most of the time the parts edited in a file do not overlap. So they merge nicely. its only the very rare times that there is conflict. I think this is mostly due to how open/transparent we are on who is doing what and we rarely have to step on each others toes.

Always update before commit.

What will happen if you've altered a file that someone else altered in the meantime is NOT a complete overwrite of everything you've done. It usually doesn't even cause you a problem unless its directly to the same PORTION of that file that changes were made.

Spoiler :

More often than not it will harmlessly auto-merge the changes in so that when you do go to commit you don't overwrite everything they just did with a file that doesn't include their changes.

If there IS a direct conflict then it will let you know when you update that there are files in conflict. Right click on those conflicts and select the option to open up the onboard compare program with those files. The compare program is quite easy to use though it may take some playing around with to figure it out. I'm sure as a gamer you can quite easily figure out how to get it to do what you want it to but if you get reeeeeealy stuck let me know and I'll walk you through the stuff... it's just that it tends to be more complex to explain than it is to figure out.


That said, I did NOT update before my last commit because I knew there was a problem with one there and I knew that none of the files I had manipulated were altered since my last update. Additionally, I had THOUGHT there would be a way to surgically extract a particular update from the SVN stream but apparently I'm wrong so I'll recompile a new dll here since I've already moved on from that one and re-commit tonight.

You are both correct.

 

[Hydromancerx]

Always update before commit.

I always thought it was ...

Step 1: Update your SVN to get the latest copy of the files.

Step 2: Edit the Files.

Step 3: Upload your edited to the SVN

Step 4: Update your SVN for anything changed while you were editing.

Are you saying step 3 and 4 should be swapped. If so how will the SVN know you want to keep the most updated stuff and not replace it?

For instance lets say I want to change the Strength of a unit from 3 to 4. But someone comes in and changes it to 5. In my experience if you don't update it will tell you someone has changed it to 5 and do you want it to be 4 or 5.

However if I come in later to the file after its been changed and updated I can easily chnage the 5 to a 4. What is stopping that from happening if I update right before I commit?

Why is committing right before your change something different from updating and then changing a stat a day later? Seems like the two would have the same effect and thus not tell you that you just overwrite an important part.

 

[Thunderbrd]

Are you saying step 3 and 4 should be swapped?

YES!

If so how will the SVN know you want to keep the most updated stuff and not replace it?

Ever notice how as soon as you save a file it takes on the red ! icon rather than the green one? That's denoting files that have been altered since the last update. The SVN knows now that you've made a change to this file. It also assumes you want to keep the most updated stuff. I'll explain in answers to the following.

For instance lets say I want to change the Strength of a unit from 3 to 4. But someone comes in and changes it to 5. In my experience if you don't update it will tell you someone has changed it to 5 and do you want it to be 4 or 5.

That would be a direct conflict created. Thus when you update before committing you'll be told that file is in conflict with the current SVN files and this means, in short, you're about to screw up something someone did since you last updated if you were to commit this file without working out which of the two versions you want to keep.

Thus the file, when it comes into your fileset during the update, will be highlighted in red saying there's a conflict there and you can right-click on that file and 'edit conflicts'. If you take a look at the conflict and you KNOW that you want yours or theirs you can simply select to use theirs or yours as the file you'll keep between the two.

Otherwise you'll have to get comfy with using the merge program to sort it out. In the simple example given this is not a problem but for something much more complex that we on occasion run into with multiple dll coders it becomes a much more interesting pursuit.

However if I come in later to the file after its been changed and updated I can easily chnage the 5 to a 4. What is stopping that from happening if I update right before I commit?

I think when you commit if you haven't updated first you do get told if there's a conflict and also forced to address that conflict at that point... its just safer to resolve with an update first. Otherwise you may incidentally overwrite something someone else did without knowing you've overwritten it and that can obviously cause some major problems at points. And it can be demanding of resolution 'on the spot' without you having the luxury of working it out more carefully.

Why is committing right before your change something different from updating and then changing a stat a day later? Seems like the two would have the same effect and thus not tell you that you just overwrite an important part.

I think we've gotten lost in the terms commit and update here. We're not saying to commit right before a change (how would THAT work anyhow?) - we're saying to update right before you commit after having made changes.

 

[strategyonly]

we're saying to update right before you commit after having made changes.

B I N G O

 

[Dancing Hoskuld]

The only exception to this is when you are deleting files from the SVN. If you delete them from your local copy then do an update the SVN will restore them on your copy and you wont have anything to commit.

 

[Thunderbrd]

The only exception to this is when you are deleting files from the SVN. If you delete them from your local copy then do an update the SVN will restore them on your copy and you wont have anything to commit.

Au Contraire! This is why you must use the tortoise delete option to delete a file properly if you're intending to not only remove it from your system but also from the svn upon your next update. Right-Click, Tortoise options, delete (it's a red x).

 

[Hydromancerx]

I think we've gotten lost in the terms commit and update here. We're not saying to commit right before a change (how would THAT work anyhow?) - we're saying to update right before you commit after having made changes.

It would work like this. I have an SVN and I copy a file to work on and then stick into my non-SVN working copy that the game loads. I test out the file and see if it work. Then I come back in and replace the old file with my new file.

During this time one could update the SVN and thus the file gets updated not knowing you have a an edited copy. At this time will the updated SVN that gets replaced by the copy of the file that file know that the copy is not to replace any changes made to it?

 

[Thunderbrd]

It would work like this. I have an SVN and I copy a file to work on and then stick into my non-SVN working copy that the game loads. I test out the file and see if it work. Then I come back in and replace the old file with my new file.

During this time one could update the SVN and thus the file gets updated not knowing you have a an edited copy. At this time will the updated SVN that gets replaced by the copy of the file that file know that the copy is not to replace any changes made to it?

1) I don't work with copies like this so that may be part of the confusion. I work directly on the SVN check out directly in the mod file. So that when I test I know I've got it all. I update before testing and after the test, just before the commit so that I know if there's a sudden conflict. If there is I may need to adjust and retest then update again thereafter THEN commit.

2) You need to put the edited copy back into your fileset before you update so that it has a chance to find any conflicts when you update. You need to update WHEN your files ARE adjusted in your SVN version! Otherwise you're actively bypassing all the controls to enforce conflict resolution.

 

[Hydromancerx]

Here is a slow chart of what can happen.

Note this way allows you to still have the original SVN copy in place if you mess up. Rather than deleting the file and then updating your SVN to get an unaltered version of the original.

 

[Thunderbrd]

Which is why you should NOT use a copy - whoever promoted that idea in the first place baffled me from the beginning.

Of course that CAN happen and you should be leaving very little time between the final update and your commit to minimize this possibility. If it does still happen it will probably let you know there's a conflict and you thus can't commit and at that point it will direct you to update first.


Hey Alberts... I had the problem you pointed out, checked out a whole new SVN repository and made the changes I'd made previously and then trying to commit THAT I get THIS at the end of the attempt:

Error: Commit failed (details follow):
Error: Youngest revision is r7770, but rep-cache contains r7771

What the hell is the rep-cache???

 

[olduser]

Hey Alberts... I had the problem you pointed out, checked out a whole new SVN repository and made the changes I'd made previously and then trying to commit THAT I get THIS at the end of the attempt:


What the hell is the rep-cache???

The rep-cache is on the SVN-Server in the file \db\rep-cache.db.


Edit:

I did your commit to test if it is working now.


SVN7771

• A few assorted fixes/streamlines to problem spots in the code that were being pointed out by assert messages.

 

[olduser]

Here is a slow chart of what can happen.

Note this way allows you to still have the original SVN copy in place if you mess up. Rather than deleting the file and then updating your SVN to get an unaltered version of the original.

This makes no sense to me

 

[Sparth]

Can someone tell me in simple words what was wrong with this fatal 7770 update? I dont want to make this mistake in future.

Some facts:
- before commit I made update
- I have lock problem with updating (see bug trhead) and before commiting I made fresh new SVN folder with updated fresh SVN copy
- files which I uploaded was made by my (icons) or was editet by me in this time (im pretty sure no one work on unit art XMLs in this day)

 

[Dancing Hoskuld]

Which is why you should NOT use a copy - whoever promoted that idea in the first place baffled me from the beginning.

It was given as best practice. SVN on net <-> SVN copy on machine <-> working/gaming copy

Often I don't want to update what I am working on with what others are doing but want to keep my copy of the SVN up to date because of slow internet connection.

 

[olduser]

Can someone tell me in simple words what was wrong with this fatal 7770 update? I dont want to make this mistake in future.

Some facts:
- before update I made commit
- I have lock problem before updating (see bug trhead) and before commiting I made fresh new SVN folder with updated fresh SVN copy
- files which I uploaded was made by my (icons) or was editet by me in this time (im pretty sure no one work on unit art XMLs in this day)

I'am not sure what happened but something really went wrong there.
The 7770 database file on the server had 7745 in some lines instead of 7770 and the binary diff data for the edited xml files was missing.
That was the reason i had to delete 7770 and the following commits.

 

[strategyonly]

Can someone tell me in simple words what was wrong with this fatal 7770 update? I dont want to make this mistake in future.

From what i am reading, is that you at some time probably along time ago, did not do an update before you committed and someone did a commit and you tried to do your files over his, but the SVN locked you out because you didnt do the update and a "clean up" before you committed. Or something close to this...>

 

[Thunderbrd]

The rep-cache is on the SVN-Server in the file \db\rep-cache.db.


Edit:

I did your commit to test if it is working now.


SVN7771

• A few assorted fixes/streamlines to problem spots in the code that were being pointed out by assert messages.

Well... I was able to then update that properly so here's to hoping that now sorts out the problem from here eh? lol I'll let you know if I get anything else wiggy goin' on.

 

[Thunderbrd]

Yep... that unstuck me - thanks Al!

7772
Fixes the ability of ranged assault to damage units with bAlwaysHostile.

 

[strategyonly]

7773 Changed MY new handicap system and added in World Info changes also, both of these were drastically changed. thx to Bluegenie