The differences between the various and sundry ext[0-9] filesystems are more about features, and less about structure. The advantage is that they are fairly compatible with each other. For instance, you can mount an ext3 partition as ext2 and everything should work just fine. Similarly, you can mount an ext3 partition as ext4. Whenever you do either of these operations, you won't have access to the version specific features. For instance, if you mount an ext3 partition as ext2 you will lose access to the journal. Similarly, mounting an ext3 partition as ext4 won't let you use the newer features such as decreased fsck times and extents rather than bitmaps.
In order to make the conversion what you'll need to do, at a high level, is
- unmount the partition
- run the conversion
- mount the partition
So as long as this is not your primary disk you can do this without having to take down the system, you just have to expect the target partition to be down for some length of time. And, as always, before fiddling around with your filesystem you should take a full backup of the data on the off-chance you have some loss.
The exact commands you should run to do this are as followed. For my purpose, I'm going to assume your target device is /dev/md0
umount /dev/md0
fsck.ext3 -pf /dev/md0
tune2fs -O extents,uninit_bg,dir_index /dev/md0
fsck.ext4 -yfD /dev/md0
The first fsck is to make sure that your filesystem is in a clean and sane state before we do the conversion. Otherwise the process may fail, or even worse, may succeed but leave inconsistencies laying around. The tune2fs command is for fiddling with the filesystem settings. It was originally created for ext2, hence the '2fs' part of the name, however it is used for modifying all versions of the ext filesystem. In this case we are enabling the extra features that were added between ext3 and ext4. The final fsck is doing two things. First it makes sure that any necessary cleanup from the conversion happens, and secondly it will create, or rebuild, the directory index.
After all this you will need to edit the /etc/fstab to make sure it is mounted as ext4, though in truth the auto option should correctly identify it as such.
Congratulations, so long as nothing caught fire/blew up/committed mass genocide/convicted of murdering it's wife during the process then you should be the happy owner of an ext4 partition.
Best Answer
The general answer is "no". uid and gid on the filesystem will be as set at the moment of the write and if they don't match on a different machine, then privileges won't match either.
If you do not want to make a small revolution with uids/gids on several machines, you could try using acls to set the desired permissions for all desired users on all machines. I suspect this will use numerical uids internally, so it could happen, that giving access to your account foo on machine A, uid a, will give access to your files to a random guy bar on machine B, uid a. It also seems like it's more hassle than it's worth.
I think that saner approach would be to use tar to migrate your development tree.
I have also had a half-baked idea of carrying around a Subversion repository (with files writable only to root and appropriate access configuration files), and relying on svn server being present on all machines which you are going to use, but I do not think it's excessively sane.