I am administering a repository for data analysis stored on the network filesystem, with three of running MsysGit in windows (1.8.4, W7). ignorecase is set to true in the repository.
Does anyone have any best practices for keeping the repository sane w/r/t the insane Windows capitalization settings?
Specifically (sort of), I have a directory that was (probably) changed from Utils, to utils, or vice versa. Now I am seeing all sorts of weird behavior. For instance, if I run
cd Utils
git log ../utils/foo.txt
I see two entries for the file (the original commit and an addition), but if I run
git log foo.txt
I only see one log entry.
I don't have any idea what is going on, and I know we will run into similar issues later, so if anyone has some wisdom to share I would very much appreciate it.
You can find one advise in "Git-windows case sensitive file names not handled properly", which reminds us of the current situation (even though you might be dealing with just Windows):
If you want to do development on multiple different platforms, you have to respect the restrictions of those platforms and you have to confine yourself to the lowest common denominator of all the platforms you support.
Windows supports ADS (Alternate Data Stream), Linux doesn't.
OSX supports resource forks, Windows doesn't.
BSD supports case-sensitivity, Windows doesn't.
So, on a FAT32/NTS case-preserving system:
Does anyone have any best practices for keeping the repository sane w/r/t the insane Windows capitalization settings?
Mainly:
chose a convention for using lower/uper cases, and stick with it,
Put a hook to detect and reject conflicting case conflicts,
set temporarily ignorecase to false if you need to change the case
Related
We have customers who deploy our application in WebSphere. Some use Linux others Windows. To minimize testing efforts we were looking to validate the possibility of just testing on Windows.
In theory, the risk is fairly low - the "write once, run anywhere" promise of Java holds up pretty well when you keep the app server and underlying JVM constant. Here are the general areas where (in my experience, at least) you'll need to be careful across the two platforms:
Batch/shell scripts - Not something you'd need to worry about in pure Java, but in the event you've got anything scripted outside the server process, this is something to be aware of. My guess, though, is that you wouldn't be considering skipping Linux testing if you had shell scripts to worry about.
Environment variables - Talking just about OS-level environment variables; anything you define within the server config should be safe.
File/path separators - Hopefully you're careful about using variables rather than hard-coding them so this won't be an issue.
File sorting - This is a sneaky one. Windows will sort files within a directory in a predictable order. Linux will not - it can depend on the vagaries of file system settings and maybe OS levels and whatnot. In a well-packaged app, this won't matter... but if you have any duplicate classes in WEB-INF/lib or EAR/lib, and they're not absolutely identical, it can break you. Make sure that you're not including multiple versions of any dependencies, because it's possible that the contents of those /lib directories will get pulled into the class path in different orders on different OSes (or even different systems with the same OS).
Best of luck!
I would add to #Jarid list the fact that, in Windows, file names are not case sensitive and this can cause problem depending of the technologies you are using in your applications (ie JSP file names, properties files etc). In this regards, if it works on Linux, it will work in Windows but the reverse may not be truw
It happend to us...
And also the underlying JDK may have different "behavior" and also differents "bugs" depending on the platform you use
Here's my problem. I have OSX Lion and I do Web development, BUT I have no real comprehension of what I'm doing when I'm using brew, pear, and the terminal in general. I am working on leveling up, but I still have to work in the meantime. That's why I very often mess up my system files (just tried to install PHPUnit, didn't work, so I deleted other pear directories, still didn't work, and now I end up with a mess).
It would feel better and relieve a lot of stress to know I can revert back my changes when I mess up. So my question is, can I set up a version control like git on all my computer files themselves, so that before any big change, I can save the state of my computer? Or is there any other way to get that same result?
I think creating different users for my mac is not enough, cause I want to build up my system, and add things to it, so it doesn't really help. And I'm not sure, but Time Machine is made just to get some files, not to revert my system to some previous state, or can it do it?
Help would be greatly greatly appreciated, thanks!
Seems to me you need to use a VM.
Take snapshots and work without worries. If you mess up you just revert to your last known good snapshot
You can do this - you can version control anything... but I wouldn't recommend it (at least not with GIT/SVN/etc - perhaps there's some software designed for this purpose that I'm unaware of).
You'll be tracking version changes for tons of files, temporary, setting files, binaries, etc. Files would be changing all the time and you'd need to stay on top of commits and so forth. Instead I'd recommended just copying folders (backup), making changes, verifying your changes work, then deleting the backups.
It's very easy to overuse version control.
Having an external drive with time machine and allowing it to sync often will allow you to revert certain parts (or all) of the file system to a certain date.
Since you're under OS X, I'd suggest Time Machine - it is more adapted to what you want to do than a source control versioning. TM is pretty decent at backuping, but there are other solutions if this one doesn't fit your needs.
EDIT: as commented by #dstarh, brew isolates everything it installs and uses symbolic links when needed. So use it whenever you can, it leaves your system cleans. There's instructions on how to uninstall a software, and in the worst of the cases, you could look at the source of your software's formula and find out what to delete.
Long story short : yes you could, but there's way easier and painless ways to do this.
I actually know that it's better to have an version control, but I wonder if Time Machine doesn't make a good job on this for lazy programmers?
Because TimeMachine won't track the log of file changes.
e.g. for a given file in Subversion I can easily determine when it changed, and what else changed at the same time.
It won't tell you who changed it, but I assume you're discussing single-user cases in this instance.
And finally you can't tie checkins and changes to builds/deployments.
Installing Subversion (or similar) on Mac OS is trivial, and won't consume resources unless you're checking in/out. It's strongly recommended. And of course make sure your repository is backed up with TimeMachine!
They're actually very similar, but Time Machine doesn't keep track of what version of a file matches a particular build of the system. It's very useful to have the metadata.
Time Machine does not keep all backups (it only keeps hourly backups for a day, and only keeps daily backups for a month), so you will not have every version of the file if you need to go back and figure out exactly what change introduced a problem. It doesn't have diff support built in, though you could probably do a diff -r on the directories in question. It also does not record any commit messages, which can be invaluable in figuring out why someone changed the code in a particular way. Finally, it does not help you coordinate between multiple people or one person on multiple computers; one of the biggest benefits of version control is that it helps you distribute your code and merge in changes from multiple people.
If you want to have quick and easy version control, I'd recommend one of the distributed version control systems. Unlike centralized systems where you have to set up and administer a server, getting started with a distributed system is usually as easy as git init; git add .; git commit. I generally prefer Git, but Mercurial is also a good choice and some find it easier to get started with.
Time Machine will give you backups of your code. That's it.
Source Control will give this as well, but provides a lot more as well. The biggest is branching and merging, which is a huge help on projects.
Time Machine also won't store metadata like checkin comments, or who made what changes.
Finally, Time Machine can't really be distributed. If you want someone else to start working on your code as well then Time Machine won't help. But (good) source control would make collaboration very easy.
The single most important and valuable thing in a version control repository is not the content, it's not even the history (that's #2), it's the commit messages. And you don't have those in a backup program.
On the PC, active backup does pretty much the same thing, and also allows revision comparison albeit limited to file by file basis. The problem comes when you want to do something like list all the differences between version X and version Y, with the intention of building version Z based on a combination of the two. These type of backup systems are ok until you are simultaneously maintaining multiple versions of the same project.
Branches & Tags?
For the reasons everybody else has pointed out, use source code control. It's easy to set up and will solve a lot of problems. It will tell you who changed what when, and why (if you use commit messages properly), and give you details. It's invaluable when you realize that something went wrong within the past few days.
Once you've done that, use Time Machine to keep backups of the repository. A version control system is not a backup system. Nothing is safe that is only on one file system.
dont forget about branching, it's one of most powerful tool a SCM can give you.. I dont know if time machine has some kind of 'alternate reality' feature
At work I use ClearCase and SourceSafe, but have found some time to do some time to code for myself enroute thanks to a disposable laptop.
However, I wish I had a lightweight VCS on my system using which I would be able to make changes to my code during the commute and then push/grab them from my Linux systems.
I use git on my home system, but I can't really get it working on Windows. I don't want all that cygwin hack.
If it does not run natively on Windows, it just won't do.
What have you guys tried on your Windows system? Something that YOU use.
The big player at the moment seems to be Mercurial?
What would be best for a one (or maybe two) man team?
I just need to maintain :
Versioned copies of source code.
Checking in and out should be as less obtrusive as possible.
I am looking forward to a multiple Undo kind of feature (like that in an EMacs buffer) but persistent.
I really like the way git keeps track of lines moving between files in a source code set
I should be able to move part(s)/sub tree(s) of the source tree (each sub tree implies a module/plugin to my the main software I am building) to an archival system either completly or partially and restore them back from the archive as and when required and the system should track any changes to this tree as well.
I actually want to experiment with my code as much as possible without me manually keeping track of what I modified and what I need to undo once I try out some idea, so that I am back to where I want to continue from.
Notes : A similar topic came up a year ago : DVCS Choices - What's good for Windows?
I hope things have changed, and I really want people to share their own, real life experiences. Not something they recommend without using it or they think will work.
Bazaar and Mercurial both work very well on Windows. I posted in the question you linked, and since then, both have improved their Windows support even more. Using them is easy and flawless, and they even have GUIs if you swing that way.
I for one have switched from bazaar to git, and I've been pleased.
If you've a Clearcase background, why don't you take a look at Plastic SCM? Check this link, it will show you how it works on a distributed setup (and of course all the basic operations) http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html.
You won't miss any of the "good" clearcase features but all the shortcomings are simply gone (faster, installs on 45seconds, no cumbersome setup to use on a mixed Win/Linux scenario, built-in ACLs, excellent branching and merging, much better common ancestor algorithm, visualizations, better GUI, and you still have "selectors" in case you miss config_specs, but not being mandatory)
Assuming that I'm starting a new web project at home using Visual Studio, which version control system, viz. Git or Subversion will be better to use? Which one will have the least setup complexity?
Since this is for your own personal playing around, my question is simple: Do you know Subversion or Git already?
If you know SVN - use Git.
If you know Git - use SVN.
If you don't know either - use SVN. It's a better introduction.
I'd go with Git. It's not that bad getting up to speed on the basics (there are now a ton of good resources, including learn.github.com) and it'll pay off in spades. And I've been using it on Vista with no probs.
Subversion is far more Windows-friendly in my experience and also more immediately useful for the solo developer.
Another possibility is Perforce, which is slightly less Windows-friendly, but full featured and fairly easy to use, not to mention free for up to two users.
Git is a distributed source control setup and as you are the only user I can't imagine that you would benefit much from its features. Subversion is (in my opinion) easier to set up so I would recommend you go with it.
If you are working alone and want some kind of version control easy to use, then use Subversion.It works great on Windows, setting up the repository is one right click in an empty with Tortoise SVN. Ankh SVN provides a very good integration with Visual Studio - almost on par with TFS provided you use VS 2005 or more recent.
On the other hand, Git is much more promising than SVN. I'll check it during this year, but third party tools are not on par yet.
I'd go with Mercurial instead. It's supposed to be similar to Git (which I never could get running because of the Windows issue) and is really easy to setup in Windows & very nice for "personal" version control systems.
Which one you decide to use depends a lot on what your needs are now and going forward. Git has a very nice community built a round it with GitHub which is great for sharing code and projects. SVN is pretty simple to setup and get going, but in large teams Git has it beat hands down with it's branching and merging. This is ideal in cases where you have multiple people working on the same project, either in an office setting or an OSS sense where the team is spread out.
If all you need is something quick and simple to setup and get going so you can start your project, SVN should be fine. SVN is also integrated into many editors and IDE's as well as many bug tracking and continuous integration systems.
If you plan on having a team, or already do, Git is worth looking at for its branching and merging setup. Git however, due largely to still being kind of young, doesn't have nearly as much support available
If you want Visual Studio integration there is no question. Only Subversion has Visual Studio integrations (AnkhSVN, VisualSVN and several scripts that allow access to TortoiseSVN).
One of the most important reasons that Subversion has such a large amount of tools written for it is that it was designed as a stable library for use by multiple clients.
It's unlikely that Git gets the same level of integration in Visual Studio before git support is available as some kind of reusable library. (There are plans for a libgit2 that could make this a reality).
Let's my ride-in on your question and ask:
Does Git work on Windows?
Does it have something that's equivalent to Tortoise? (otherwise I don't see how it could compete with SVN in terms of ease-of-use)
On a side note: If it's really a one man home project, you don't really need any source control tool. Just put your project in a DropBox folder and you're done (auto-commits, infinite revisions, undelete).
Unless you really think you're going to need tags and branches and stuff. But for personal home projects... do ya?
You can make your own opinion after reading this : http://whygitisbetterthanx.com
Git................................(these dots are there because SO wont accept a 3 lettered answered).
A great answer to this question was recenting written about by Jack Repenning here:
If you have compelling requirements for a single, certain, master copy of your work, use Subversion. You can do this with Git, so long as there are no slip-ups. But you can’t do anything else with Subversion (slip-ups or no), and “compelling requirements” like Sarbanes-Oxley are happier with guarantees than possibilities.
If you plan to maintain parallel, largely shared but permanently somewhat different lines of the same product, use Git. One common example: perhaps you have a large product that you customize for each customer. The customizations are permanent, and generally not shared among code lines, but most of the code is common to all. Git was designed for just this case (in Git terms, local customizations to the common core, and occasional feature or bug-fix contributions back up-tree)
Neither of those? Take your pick, you should be fine with either tool.*
Full Blog Post here: http://blog.codesion.com/post/15692788883/subversion-or-git-decisions-decisions
With SVN you will have to set up a server, create a repository there, check out the (empty) repository, add your files, and then commit.
With Git, all you need is git init in your project's root directory. Then you can add and commit files as you see fit.
There's not really any idea in setting up a Subversion server, since you're the only one working on the source. Contrary to what many people think, solo projects is a perfect match for distributed version control tools. It's also very easy to grow your project later on.
In my experience, Subversion is easier to "grok", but Git is faster and easier to engage in software development best practices. As a former CVS user, Subversion made immediate sense to me when I started using it. Git took some study and I still have to refer to the manual from time to time, but I love how easy it is to branch and merge code when I've got to maintain a release process.
If you are already familiar with CVS and just need something to keep your history and diffs, Subversion will be easier to get started with. If you are new to version control, the tide is shifting toward DVCS in general and Git in particular, so you may get more mileage out of that in general.
I do recommend you look at a hosted provider so you don't have to worry about setting up a Subversion server or so you can have a backup location for your Git data. You can Google for "subversion hosting" or "git hosting" to see the premier providers in the space.
If you plan to take your project along on an USB stick, use Subversion. Windows XP it really, really, really bad at caching lots of small files on an USB stick. Git writes many small files for commit operations and that takes ages on Windows.
[EDIT] The problem with Windows XP and files on an USB stick is caching (or the lack thereof). To prevent data loss, XP will always write files synchonously on an USB stick (so any write will come back only after the FS has reported that all blocks have been written to the stick). Add that to the fact that USB sticks are slow when handling small files (they have a lot of overhead initializing their wear level management) which leads to very poor performance for any kind of application which writes lots of small files.
[EDIT2] If you put a SVN checkout on the USB stick, you will also have a lot of small files (especially in the .svn directories). So the solution in this case is to put the Subversion repository (the "server") on the USB drive. The repository uses only a bunch of big files (if you use the database option instead of the file based one: svnadmin create --fs-type bdb). This avoids the "many little files problem". There is no way to achieve the same thing with current versions of Git.