Questions about DVCS

Hey,
I have been reading about DVCS, Git and Mercurial.
Git has about 139 commands implemented as Perl and shell scripts, the quality of many of them is under question.
Should I know the whole Git commands in order to be effective? or 15 or 20 command will be sufficient?
DVCS are poor when it comes to binary files, does this mean DVCS aren't suitable for Java projects (imagine a lib dir that contains tens of Jar files)?
Thanks for help and time.

Subversion for example doesn’t store revision history on the client.
If you check in fifty revisions to an incompressible 10MB file, Subversion’s client-side space usage stays constant. The space used by any distributed SCM will grow rapidly in proportion to the number of revisions, because the differences between each revision are large.

I would question why you are checking in binary files in the first place.

If you are talking about jar files (presumably from other projects), then you would almost certainly be better off using Maven or Ivy as a dependency manager and only check in the very small file that it uses. Then allow the dependency manager to get the correct version of the external dependency for you.

What should go into VCS?
Every thing necessary to build the project, right?
Please correct me if I got you wrong:
My project is using Hibernate, hibernate.jar should go into VCS and let Ivy -for example- get the dependencies (like log4j, dom4j ..)?
I have a rule:
I have to be able to build the project any time I want to, the process shouldn't require external resources (like a network connection).

Usually I only put the raw sources into VCS and maybe the finished products (especially if that's where the operations support staff will retrieve them for installation). Intermediate stuff such as compiled classes only waste resources, since they change often, don't compress easily for version deltas, and should be fully re-creatable using the build process. Which, I sincerely hope doesn't consist solely of running an IDE's build to produce production modules (I've been really badly burned by that more than a few times).

Maven and Ivy are good for this sort of offline build, since you can keep single instances of your library jars in your local repository and they'll be accessible for all projects to build instead of having to waste a lot of space replicating libraries for each project. That includes not only the low-level stuff such as log4j.jar, but the higher-level shared resources like hibernate.jar, and even any common shared code of your own authorship.

I suspect the average VCS user knows maybe 5 commands, assuming they're not hopelessly addicted to GUI interfaces and don't know any of them at all. Most of the more extensive commands are either administrator commands or only used infrequently.

Customer surveys are for companies who didn't pay proper attention to begin with.

John Todd wrote:My project is using Hibernate, hibernate.jar should go into VCS and let Ivy -for example- get the dependencies (like log4j, dom4j ..)?

The key word I see there is "using". Since you are only using hibernate, I would consider it a dependency, and not check it into my VCS.

John Todd wrote: I have to be able to build the project any time I want to, the process shouldn't require external resources (like a network connection).

Tim Holloway wrote:Maven and Ivy are good for [...] offline build, since you can keep single instances of your library jars in your local repository and they'll be accessible for all projects to build instead of having to waste a lot of space replicating libraries for each project. That includes not only the low-level stuff such as log4j.jar, but the higher-level shared resources like hibernate.jar, and even any common shared code of your own authorship.

To put that another way - both Maven and Ivy have their own private directories where they keep your external dependencies. This is a standard setup - no special configuration needed by you.

So the very first time I want to build your project, I run (as an example), two command while connected to the internet: "svn co http://......" followed by "mvn clean install". If this is the first time I have ever run maven on this particular computer, then I get to see in the output that maven has downloaded hibernate and log4j.

So far this is not really any different than if you had checked hibernate and log4j into your cvs - in both cases they have now been downloaded over the internet.

I can now disconnect from the internet and continue working (including running maven builds) without any problem.

Now for a big change: for some reason I decide to wipe out my copy of your project. Having deleted it from disk, I then re-run "svn co http://...." and re-run "mvn clean install". However in this case maven knows that hibernate and log4j were downloaded previously, so it uses the cached copies. I have spent far less time downloading over the internet!

Likewise, if I were to now start work on a totally unrelated project that also just happens to use hibernate and log4j, then maven will also grab them from the cache.

I have 73 projects on my computer at the moment - a mixture of personal projects, projects for friends, work stuff, and JavaRanch stuff. Most if not all of them use Log4J. It turns out that I am using three different versions of Log4J (I don't know why). But since most of them are Maven enabled, I only downloaded each version once from the net - the rest are just re-using the cached copies:

As an aside - at the time of downloading the jar files, Maven checks the md5 checksum, and if they do not match it retries the download. So it is rare for a cached version of a jar file to get corrupted. However if I did suspect that it was corrupted, I could always delete it from the Maven repository.

As you can see, in some cases I have told my Maven projects that I want source code downloaded as well (useful for IDE command completion, and for debugging). Whatever uses version 1.2.9 of Log4J is obviously an inherited project, since sources are not downloaded.

My maven cached repository is currently sitting at 99 Mb. Not really a problem space wise.

Tim Holloway wrote:I suspect the average VCS user knows maybe 5 commands, assuming they're not hopelessly addicted to GUI interfaces and don't know any of them at all. Most of the more extensive commands are either administrator commands or only used infrequently.