Sryx Posted December 2, 2012 Group: Members Topic Count: 15 Topics Per Day: 0.00 Content Count: 520 Reputation: 64 Joined: 11/19/11 Last Seen: April 20 Share Posted December 2, 2012 (edited) Tabs is much easier and small file size. Edited December 2, 2012 by Rejected Link to comment Share on other sites More sharing options...
malufett Posted December 2, 2012 Group: Members Topic Count: 9 Topics Per Day: 0.00 Content Count: 554 Reputation: 70 Joined: 04/04/12 Last Seen: November 8, 2013 Share Posted December 2, 2012 Bump for GreenBox ... 1 Link to comment Share on other sites More sharing options...
MarkZD Posted December 2, 2012 Group: Members Topic Count: 6 Topics Per Day: 0.00 Content Count: 134 Reputation: 35 Joined: 02/27/12 Last Seen: April 5, 2022 Share Posted December 2, 2012 Any of the Core Devs feel free to take care of this as I'm out of commission this weekend as posted. Thanks, Cookie I'm marking it as approved as the majority is in agree. Link to comment Share on other sites More sharing options...
lekkereten Posted December 2, 2012 Group: Members Topic Count: 8 Topics Per Day: 0.00 Content Count: 148 Reputation: 46 Joined: 11/02/11 Last Seen: August 20, 2020 Share Posted December 2, 2012 Yes, now SVN Blame will blame the person who committed the TAB-to-spaces conversion. And when we revert this, SVN Blame will blame that person too! We'll have to do two "Blame previous revision" lookups to find out who actually added/edited a line! The only way to prevent that is: undo r16968 by doing SVN Replace on the whole /trunk/src/ (replace it with revision 16967 of /trunk/src) have everyone re-commit r16969 to r16991 (23 commits) then do the proper AStyle conversion (4 spaces = 1 tab)- this will still cause converted lines to blame the wrong person(and when looking up SVN Blame you have to do "Blame previous revision")+ but at least you only have to do Blame previous revision ONCE+ and it will only be for the lines that were space-indented, then converted to tabs(I'm guessing less than 5% of the code? The majority of it was already indented with TABs prior to r16968.) I'm FOR doing this. We replace with the source from r16967, which was actually last-modified in r16966 (doesn't matter much). Then we could do this: • Either every one recommit their own commit, so blame will be properly placed which will take more time (depends on that dev's activity) which I strongly recommend we do this, regardless of revision number, at least we'd have blame righty (partially, source-related would be different but still blame the same person). Also I'd go for keep commit AS IS even if they would be reverted or follow up'd after, for the sake of blame. • Otherwise we take a single person to recommit everything and even though we'd have less "useless" revisions (or follow ups), blame would be broken. (which I don't like) And since this code style thing is giving so much trouble (which I thought it wouldn't), personally I don't want this kind of headache anymore, so leave it be. List of commits envolving source modifications and its authors: http://trac.rathena.org/changeset/16988/rathena - malufett http://trac.rathena.org/changeset/16987/rathena - ligtha http://trac.rathena.org/changeset/16986/rathena - mkbu95 http://trac.rathena.org/changeset/16985/rathena - mkbu95 http://trac.rathena.org/changeset/16984/rathena - markzd http://trac.rathena.org/changeset/16981/rathena - malufett http://trac.rathena.org/changeset/16980/rathena - markzd http://trac.rathena.org/changeset/16979/rathena - markzd http://trac.rathena.org/changeset/16977/rathena - akkarin http://trac.rathena.org/changeset/16974/rathena - mkbu95 http://trac.rathena.org/changeset/16973/rathena - mkbu95 http://trac.rathena.org/changeset/16971/rathena - mkbu95 http://trac.rathena.org/changeset/16969/rathena - lighta 2 Link to comment Share on other sites More sharing options...
MarkZD Posted December 4, 2012 Group: Members Topic Count: 6 Topics Per Day: 0.00 Content Count: 134 Reputation: 35 Joined: 02/27/12 Last Seen: April 5, 2022 Share Posted December 4, 2012 I am starting to work on this now. Complete. Here's the diff, if someone want to check: http://www.mediafire.com/download.php?peh69n9fbvadwr1 Patch the revertTo16967 before. I pretended to commit it a little later, but not sure after talking to mkbu95. It'd be good if we could make a meeting with everyone at irc. 1 Link to comment Share on other sites More sharing options...
Vach Posted December 5, 2012 Group: Members Topic Count: 21 Topics Per Day: 0.00 Content Count: 326 Reputation: 19 Joined: 09/27/12 Last Seen: February 27, 2021 Share Posted December 5, 2012 So this isn't a live update yet in the SVN? Link to comment Share on other sites More sharing options...
MarkZD Posted December 5, 2012 Group: Members Topic Count: 6 Topics Per Day: 0.00 Content Count: 134 Reputation: 35 Joined: 02/27/12 Last Seen: April 5, 2022 Share Posted December 5, 2012 Implemented at: 16992 We opted by replacing the src svn with the old version 16966. And since this code style thing is giving so much trouble (which I thought it wouldn't), personally I don't want this kind of headache anymore, so leave it be. We agreed. Link to comment Share on other sites More sharing options...
Brian Posted December 5, 2012 Group: Members Topic Count: 75 Topics Per Day: 0.02 Content Count: 2223 Reputation: 593 Joined: 10/26/11 Last Seen: June 2, 2018 Share Posted December 5, 2012 (edited) The only way to prevent that is: ✔ undo r16968 by doing SVN Replace on the whole /trunk/src/ (replace it with revision 16967 of /trunk/src) ✔ have everyone re-commit r16969 to r16991 (13 commits to /trunk/src) then do the proper AStyle conversion (4 spaces = 1 tab)- this will still cause converted lines to blame the wrong person(and when looking up SVN Blame you have to do "Blame previous revision")+ but at least you only have to do Blame previous revision ONCE+ and it will only be for the lines that were space-indented, then converted to tabs(I'm guessing less than 5% of the code? The majority of it was already indented with TABs prior to r16968.) Part 1 is done. Part 2: 16969 = r16993 16971 = r16994 16973 = r16995 16974 = r16996 16977 = r16997 16979, 16980 = r16998 16981, 16988 = r16999 16984 = r17000 16985 = r17001 16986 = r17002 16987 = r17003 Edited December 5, 2012 by Brian 1 Link to comment Share on other sites More sharing options...
Recommended Posts