In Subversion I can checkout a sub-tree of the repository. Can I do something similar with bazaar?
No, this is not posible at the moment although there are plans to add this in future releases.
Related
It appears that there's no ivy:unpublish task (e.g. see here).
So, I suppose that unpublished should be performed at the filesystem level either manually or through an Ant task that deletes ~/.ivy2/local subfolers? (when the aim is to unpublish from the local ivy repo).
I'm very surprised you accepted Mark's answer, given that AFAICT it has nothing to do with your use-case, which is about your local repository - that is, your private repository on your system. His answer is relevant to shared repositories only.
There's a use case with Ivy that I suspect is very common. A developer is temporarily working on two projects, one of which is dependent on the other. While they are doing this work, they publish SNAPSHOTs from the upstream project to their local repository, so that the downstream project "sees" their changes. When the developer is done with this task, they check in their changes into source control, and then want to "rejoin the group" and get the latest SNAPSHOT dependencies for the upstream project. At this point they want to "unpublish" the upstream project from their local repository, so that they resume consuming changes from other developers in the group.
For what little it's worth, see also this Ivy Jira issue, from 2006.
As I noted in my comment there, from a couple of weeks ago, I suspect there's some best-practice that I'm not aware of, that makes this moot. Anyone?
No, ivy does not support an unpublish action. Similarily Maven does not support such an operation.
Not sure I understand the use-case. When one "publishes" content it would normally be a very bad idea to remove it later... Why?
You could unpredictably break other people's builds that depend on your version.
Repository caches normally assume that released artifacts never change. If there exists a possibility that they might disappear, this forces a cache to constantly "dial home" to ensure they aren't dirty.
Having said that there are arguments for an against. I'd recommend reading the following excellent blog article from sonatype:
http://blog.sonatype.com/people/2012/01/releases-are-forever/
New to Apache Ivy and I'm configuring the latest-strategies element in my settings file, and am opting to go with the lexiconographic strategy for a number of reasons. But something just dawned on me, and has me worried about Ivy in general. I'm sure I'm just not seeing the "forest" through the "trees", but I absolutely need to gain clarity on this before I can proceed.
My project will use several other homegrown JARs as dependencies. Other developers may be actively working on these other JARs, and may introduce a bug at some point. If my project uses Ivy to always pull down the latest version of these other dependencies, then Ivy may inadvertently pull down a new bug when it goes to build.
What's the common solution here, or what do best practices dictate?
Is there a way to cherry pick which versions of which JARs my project uses? That way I'm not concerned with latest-strategies at all, or lexiconographic order, etc. That would seem to alleviate the problem, but may violate best practices.
Any input is appreciated, as always!
In such situation we used to use tags on trunk. When developer creates tag he must change a version number of a published ivy module. In this case when you want to use stable version of module you could resolve it by certain version (1.2.3) or by latest version from some range (1.2.+). The latest-development strategy pull out the latest unstable trunk or branch version of a module.
I feel that using Git submodules is somehow troublesome for my development workflow. I've heard about Git subtree and Gitslave.
Are there more tools out there for multiple repository projects and how do they compare ?
Can these tools run on Windows ?
Which is best for you depends on your needs, desires, and workflow. They are in some senses semi-isomorphic, it is just some are a lot easier to use than others for specific tasks.
gitslave is useful when you control and develop on the subprojects at more of less the same time as the superproject, and furthermore when you typically want to tag, branch, push, pull, etc all repositories at the same time. gitslave has never been tested on windows that I know of. It requires perl.
git-submodule is better when you do not control the subprojects or more specifically wish to fix the subproject at a specific revision even as the subproject changes. git-submodule is a standard part of git and thus would work on windows.
git-subtree provides a front-end to git's built-in subtree merge strategy. It is better when you prefer to have a single-repository "unified" git history. Unlike the subtree merge strategy, it is easier to export changes to the different (directory) trees back out to the original project, but it is not as automatic as it is with gitslave or even git-submodule.
repo is in theory similar to gitslave, but not as well documented for non-android operations that I have found. It is fairly dedicated to the Google Android development model and only natively supports a handful of git commands (though you can run arbitrary commands) and the limited native support doesn't support, for example, a centralized repository to push to and checking out a branch seems fairly difficult.
kitenet's mr is what you would want to use if you have multiple version control systems in use, but is mostly limited for git-only superprojects due to its lowest common denominator approach. There are ways to run arbitrary commands, but they are not as well integrated.
For some use cases, I have liked each of the following two simple approaches:
Nested repositories. If your software project has a plugin mechanism, with each plugin in its own sub-directory, it can make sense to git-ignore these plugin directories and, in your local filesystem, to make each of them into its own git repository. This way, all your files form a single directory tree, but are managed in different git repositories. It will not confuse git.
Per-package repositories. For software projects where you use some kind of source code package management system (gem / bundler, npm, pear or the like) it can make sense to put your re-used code into separate git repositories, then to make source packages from them, and then to install them with the package management tool into the parent project. Your parent project's git repository would only contain a reference to the required packages and their versions, while the actual code of these packages will be git-ignored as done with all other packages and external libraries as well. Compared to the nested repositories proposed above, this is a more elaborate approach as it allows to specify which package version is to be installed.
I currently use submodules for development and not just relating 3rd party libraries. There are some ways that you can make life easier with submodules, especially when they are the source of merge or rebase conflicts. Look to ls-tree to get the 2 commits involved on a conflict in the submodule. This is probably the most difficult part of submodules for people to deal with. For now scripting will make this much easier to work with. Future versions of Git should have better native support for dealing with them.
Hope this helps.
We encountered a similar issue when using Git submodules in projects where we had dependencies in a variety of languages. To deal with them, we built and open-sourced a tool called MDLR ("Modular") that gives you declarative version-controlled Git dependencies with similar functionality to Git submodules, but without the annoying workflow. You can install it and manage your dependencies with the instructions/downloads on the GitHub repo
can anyone give an detailed procedure on how to
migrate projects from gforge version(4.5) to teamforge version 5.2.0.
Migration includes source repository, bug tracking, wiki and discussions.
is it possible to shift all of them.
What's the best way to handle a situation like this?
Thank
You
Teamforge uses Subversion, so assuming you have commandline access to the server then you can use the svnadmin dump and svnadmin load commands.
You will need to run these commands for each repository.
Some (I don't know which) of the pages and wiki are also stored in subversion repositories, so you may be able to migrate that using the same method.
In a pom.xml, when specifying a dependency version, what is the difference between LATEST and [0,) ?
In my opinion they should be equivalent, but for some dependencies, LATEST does not match any version, whereas [0,) does.
In my opinion they should be equivalent, but for some dependencies, LATEST does not match any version, whereas [0,) does.
In theory, LATEST is the latest released or snapshot version (see Rich Seller's excellent answer on the special RELEASE and LATEST versions) so I would indeed expect the same behavior as with the [0,) range. Out of curiosity, can you provide an example where LATEST doesn't match?
That being said, I don't recommend using the LATEST nor RELEASE special versions as they make your build more fragile and harm the build reproducibility (you don't really want your build to suddenly start to fail because of some uncontrolled update). Admittedly, they're considered as a bad idea and references have been removed from the documentation (except from an untranslated part of the German version of the Definitive Guide)
and they are no longer supported in Maven 3.x.
You are thus strongly invited to not use them at all (bad practice, deprecated, not supported in the next version).
And I somehow consider the same applies to version ranges (in general), I don't recommend them either as I wrote many times in previous answers or comments. See for example:
Managing maven dependancies - New Versions and Non-Repo libraries
Maven automatic SNAPSHOT update
Debugging Maven’s “The artifact has no valid ranges”
Follow-up after comment
Here's an example (among many):
<dependency>
<groupId>aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>[0,)</version>
</dependency>
-> matches version 1.5.3 Whereas:
<dependency>
<groupId>aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>LATEST</version>
</dependency>
-> cannot be resolved
I'm not 100% but I don't think this artifact is providing the right maven-metadata.xml for this feature to work. I think metadata should include <release> and <latest> elements like for maven plugins (see for example this maven-metadata.xml). But I wouldn't spend too much time on this for the aforementioned reasons, just forget this LATEST stuff.
When you depend on a plugin or a
dependency, you can use the a version
value of LATEST or RELEASE. LATEST
refers to the latest released or
snapshot version of a particular
artifact, the most recently deployed
artifact in a particular repository.
RELEASE refers to the last
non-snapshot release in the
repository. In general, it is not a
best practice to design software which
depends on a non-specific version of
an artifact. If you are developing
software, you might want to use
RELEASE or LATEST as a convenience so
that you don't have to update version
numbers when a new release of a
third-party library is released. When
you release software, you should
always make sure that your project
depends on specific versions to reduce
the chances of your build or your
project being affected by a software
release not under your control. Use
LATEST and RELEASE with caution, if at
all.
See, for further information regarding this topic.
Make sure that the artifact you're looking for is present in your local repository.
However, I have to warn you about the LATEST and RELEASE version markers, as the documentation extract says, it is consider a bad practice to work with those. In fact, I think the LATEST and the RELEASE version markers will no longer be supported in Maven 3.X.
My recommendation is that you drop it usage completely and stick to the specific version notation.
EDIT:
Here is a POST that addressed this exact same information, but more thoughtfully.
Thanks to #Pascal Thivent for the observation :) I always include reference to the other StackOverflow questions that deal with the same subject I'm discussing.