Syncrhonize with SVN

[DJuego]

Hi! I am unable to syncrhonize with the RPTOOLS subversion repository.

I get:

update M:/Maptool Development/workspace/maptool -r HEAD --force
Attempted to lock an already-locked dir
svn: Working copy 'M:\Maptool Development\workspace\maptool\src\net\rptools\maptool\language' locked

Any idea? Thanks!

DJuego

[jfrazierjr]

Hi! I am unable to syncrhonize with the RPTOOLS subversion repository.

I get:

update M:/Maptool Development/workspace/maptool -r HEAD --force
Attempted to lock an already-locked dir
svn: Working copy 'M:\Maptool Development\workspace\maptool\src\net\rptools\maptool\language' locked

Any idea? Thanks!

DJuego

If your on windows, it may be because there are two copies of the German properties file that differ only in case. Of course, this is just a guess...

[Rumble]

Hi! I am unable to syncrhonize with the RPTOOLS subversion repository.

I get:

update M:/Maptool Development/workspace/maptool -r HEAD --force
Attempted to lock an already-locked dir
svn: Working copy 'M:\Maptool Development\workspace\maptool\src\net\rptools\maptool\language' locked

Any idea? Thanks!

DJuego

If your on windows, it may be because there are two copies of the German properties file that differ only in case. Of course, this is just a guess...

Yep, that's the issue. I can't check out code either, anymore. Per the suggested fixes I've read about, one of the two copies of the file has to be removed from the repository before it will work.

[Azhrei]

So what do the poor Windows users do when a locale file needs two entries in the same directory? (The "i18n_de" file is the base language file and "i18n_DE" is the region file.)

In our case we could probably delete whichever one is the oldest. I'll send a note to Trevor.

[Rumble]

So what do the poor Windows users do when a locale file needs two entries in the same directory? (The "i18n_de" file is the base language file and "i18n_DE" is the region file.)

No idea. Windows is case-preserving, but not case-sensitive; in this case, the SVN folks need to work around Windows or not have Windows-using developers, I guess. Mac OS isn't case-sensitive unless you set it that way, IIRC (been awhile since my Powerbook went tango-uniform, though, so I don't know if case-sensitivity is now standard with Leopard / Snow Leopard).

[Azhrei]

Yeah, HFS+ (the default filesystem on Macs now) preserves case. But it looks like while it works I still get only a single file (the lowercase one in this situation). Not sure why the Eclipse plugin (Subclipse) isn't giving me any errors or warnings...

(I'm not using the case-sensitive version of HFS+. It's an option when creating the HFS filesystem. No option at all for the Windows users though. )

[Rumble]

Yeah, HFS+ (the default filesystem on Macs now) preserves case. But it looks like while it works I still get only a single file (the lowercase one in this situation). Not sure why the Eclipse plugin (Subclipse) isn't giving me any errors or warnings...

(I'm not using the case-sensitive version of HFS+. It's an option when creating the HFS filesystem. No option at all for the Windows users though. )

Huh, interesting. Sounds like HFS is somehow smart enough to handle it (or to hide its wrenching internal debates from you).

[DJuego]

Thank you very much for your swift answers!

Nowdays (and very unfortunately) I have not easy access to not-Windows OS nowdays.

In our case we could probably delete whichever one is the oldest. I'll send a note to Trevor.

I will expect anxiously any news. I wish to become absorbed by the code...

DJuego

[jfrazierjr]

For those who already have an older copy of Maptool source downloaded and installed, you can manually sync up only specific folders and exclude others(such as the broken properties files.

[Rumble]

For those who already have an older copy of Maptool source downloaded and installed, you can manually sync up only specific folders and exclude others(such as the broken properties files.

Ah, right, that might do it. I can put them on "ignore".

Turns out I actually do have a clean copy of the code from...the 27th of February. So not too long ago.


Edit: interesting. I can check out the code now, and it doesn't include the German files at all.

[Azhrei]

I guess Trevor got my note.

[DJuego]

Sadly, the trouble persist for me ( ). And I have not a older copy of Maptool source downloaded and installed. Sigh!


svn: In directory 'M:\Maptool Development\workspace\maptool\src\net\rptools\maptool\language'
The system cannot find the file specified.
svn: Can't open file 'M:\Maptool Development\workspace\maptool\src\net\rptools\maptool\language\.svn\tmp\text-base\i18n_de.properties.svn-base': The system cannot find the file specified.

A M:/Maptool Development/workspace/maptool/conf/build.number

[Rumble]

Sadly, the trouble persist for me ( ). And I have not a older copy of Maptool source downloaded and installed. Sigh!


svn: In directory 'M:\Maptool Development\workspace\maptool\src\net\rptools\maptool\language'
The system cannot find the file specified.
svn: Can't open file 'M:\Maptool Development\workspace\maptool\src\net\rptools\maptool\language\.svn\tmp\text-base\i18n_de.properties.svn-base': The system cannot find the file specified.

A M:/Maptool Development/workspace/maptool/conf/build.number

Yeah, it persists for me on one computer, but not the other - my Windows 7 machine seems to have no problems with it; however, my windows XP machine is running into trouble. Unfortunately, I can't compare the two at the moment, but I will be checking to compare versions of Eclipse, Subversion, and all that stuff to see if they are otherwise identical save for OS.

[Azhrei]

Okay, hopefully I've fixed the problem with checking out the MapTool source code.

It turns out that i18n_de.properties was more recent in the repository than i18n_DE.properties. But I couldn't delete the "DE" version because my system had it as "de" instead (because it was the most recent). So I had to copy that file out of the workspace, delete it from SVN, then copy it back using the name "DE" and delete that one, then copy it back on more time using the "de" name and commit that one as a completely new file in the repository.

(I may have created a problem because I had to commit the .language package and that included i18n.properties where I've added a few properties. There isn't any code that uses those new properties, but I have added some context to the error messages for some of the JSON functions (to help locate where an error is occurring) and without a code update those error messages will likely produce invalid strings. Yet I don't want to do an update of my code until Trevor finishes whatever he has in the hopper for b63. You can see the changes to the file if you visit here. It's the additional references to "{0}" and "{1}" that might cause problems. Be aware that if you distribute a custom JAR after doing an update it will have the new properties file and that could causes weird-looking macro error messages.)

What a pain. And it took three commits to fix!

Note to self (and others!): ensure filenames are unique on case-insensitive filesystems.



Btw, for those who aren't keeping track of the repository... I have proof that Trevor isn't dead: he just updated the communitytool repository yesterday. You can see that at http://sf.net/projects/rptools.

[DJuego]

T-H-A-N-K Y-O-U VERY MUCH, Azhrei! ( )

DJuego