Matthew Wheaton <email@example.com> wrote on 12/06/2005 03:02:42 PM:
> Ok, can you see any other alternative to what I'm proposing? Do you see
> obvious flaws to my thinking in the way I have my projects laid out?
> I'm open to suggestions, my main concern is that we have a number of
> that are shared among many programs, and I wanted to devise a layout
> they are all still stored in the same repository to allow the kind of
> I've described (as I said, I came from the CVS world in this regard).
> If I were to make a patch to Subclipse to perform this, what is the
> get it incorporated, or would it probably be rejected?
> I would envision it working just as the tag functionality does now,
> that there might be a warning on the dialog indicating this is a multi
> operation exercise and that it would not ba an atomic commit.
> I just get the feeling I might have something laid out wrong if this is
> feature that has been proposed before, since it is so common in the CVS
> with Eclipse projects (that I've seen).
There is no right or wrong way to layout your repository. Your layout
doesn't seem that uncommon. If your projects are not all related, then
you could gain some advantages by grouping them by relationship. That
would let you create tags from the common parent. If in different
situations, the projects are related then there isn't much you can do.
As an example, in our repository we have folders for Subclipse,
svnClientAdapter and svnAnt. The Subclipse folder then contains several
Eclipse projects. When we make a tag, we can just use the parent
Subclipse folder for the tag.
Subversion tags are massively different than CVS. The sooner you get used
to this the better.
The best way to submit a patch is to enter an issue in the issue tracker
and attach it. I would review this patch, as long as it is thorough I am
not against it.
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Wed Dec 7 07:10:38 2005