It is unfortunate that you just flatly disagree with some of these
ideas, but I'll try to defend them as best I can:
>I do it pretty regularly. You have to create the "project" folder
>manually in the Repo browser. Then, when sharing you say "Use
>module name" and enter "Project/trunk". It is important that trunk not
As mentioned, I just tried this and it did not work...though perhaps it
could be a JavaSVN issue rather than a Subclipse issue. This begs a
larger question though: do you think it's acceptable to have to manually
create the project folder in SVN before importing anything? If Subclipse
requires the project folder to already be present, isn't it reasonable
for Subclipse to do this part? If I say to import into XXX/trunk when
XXX does not exist, isn't it fair to assume I want both XXX and
XXX/trunk created for me?
>> I believe Subclipse should be able to do the following:
>> - Import initial projects into "project/trunk". Do this all
>> but make it transparent and non-confusing in the repository view.
>This works, see above. Any UI could be easier, but it is not obvious
>me what realistic improvements could be made.
Here's the improvement I'd like to see: when I tell Subclipse to import
a project into "project/trunk", just do it, without requiring an
additional, undocumented, manual step to create "project". That would
make it simpler. I also still strongly feel that Subclipse should
default to importing projects into "project/trunk" while still providing
options to import wherever if you really want it to. See below.
>> - Create all intermediate directories in SVN to support the
>> module name.
>I think Subversion should do this. When it supports it, I will
>add that in to Subclipse. I think that will also make the process
>since you will not need to know you had to manually create the
Do you feel that Subclipse should not add any "user-friendly" features
that Subversion does not directly support? Isn't it reasonable to expect
that Subclipse would enable simple, friendly, Eclipse-aware Subversion
usage, regardless of the inherent features of Subversion itself? If you
can't just tell Subversion to create all ancestor dirs, could you not do
that in Subclipse? I think the ability to import into "project/trunk"
without any additional, undocumented, manual steps would be ideal.
The Eclipse team has done a spectacular job of making the CVS module
work better and more easily than just about every other CVS client I've
used. Where CVS has been lacking, they've developed workarounds or
frameworks to improve it. There are also other reasons why it's such a
wonderful CVS client, see below.
>> - NOT require entering "trunk" as part of the module name to
>I don't agree. I do not want to be in the business of forcing a way of
>using the tool on people. I think there are a lot of people that do
>follow the "recommendations" to the letter. The Subversion devs would
>loathe to call it a "recommendation". Just something that works well
Eclipse CVS is easy to use for a couple big reasons: it doesn't try to
do everything, and for what it does do it follows tried-and-true
standards and practices. It's a fair argument to say that Subversion
supports many different models of respository management...I won't argue
that. However, all published hardcopy documentation and most published
online documentation recommend the trunk/tags/branches layout. I would
love to see a document realistically recommending something different
and incompatible, but given the large support for this system, I think
it's reasonable to assume you're not really "forcing" much of anything.
We also need to be realistic about how Eclipse Team works. If I
understand correctly, it is not very friendly to mixing checked-out
projects in a hierarchy, at least when using CVS. Also, Eclipse works
best with (and most recommend using) a VCS-module-per-project, rather
than hierarchies of projects/dirs in either Eclipse or the VCS.
If you are aiming to make Subclipse into a general-purpose Subversion
client, with support for all the flexibility (and shapelessness) of
Subversion proper, then perhaps avoiding these limitations makes sense.
However, if Subclipse is intended to be a very Eclipse-aware,
Eclipse-friendly Subversion integration package, it should appreciate
and support the limitations of Eclipse's project environment. In other
words, sharing, tagging, and branching a project should "just work" in
some default form without requiring a user to be a Subversion expert. In
my opinion, this means DEFAULTING to using the trunk/tags/branches
layout, while not necessarily FORCING it.
>> - Show "trunk", tags, and branches as "checkout-able" in
>> view, as CVS does with projects under HEAD and individual tagged and
>> projects. (I understand SVN supports more advanced nested structures
>> repositories...but Eclipse *does not* and so it makes sense to limit
>> structure Subclipse behavior as the CVS module does.)
>It shows you your entire repository. It can checkout anything. I do
>agree it should be different.
Yes, you can check out anything...but using trunk/tags/branches, there
are fewer nodes in the repository that *make sense* to check out into
Eclipse as projects. Keep sight of the fact that "checking out" in
Eclipse almost always will mean creating a local project with contents
from the repository...very rarely will someone be checking out all of
"tags" or "branches" for use within Eclipse, because Eclipse will be
expecting .project files and friends to be in specific locations.
>> - Support creating branches and tags as simply as the CVS
>> putting them under "project/tags" or "project/branches"
>> creating ancestor directories in SVN if necessary.
>I think it already is very simple.
Here's what I'd like to be able to do, with the knowledge that
trunk/tags/branches structure would be maintained:
- Team => Tag as version, enter a name, and be done with it. Do similar
from repository view on trunk or any branch
- Team => Branch, select a base version (or base it on BASE), a branch
name, and be done with it. Do similar from repository view on trunk or
any tag or branch.
I can do almost all of this with the CVS module today. Am I expecting
too much from Subclipse?
>> - Support "replace with" and "compare with" using the
>> repository layout and the "tags" and "branches" dirs.
>This one I agree with. This needs to be added in some fashion.
If Subclipse is not enforcing or at least assuming trunk/tags/branches
layout, how will you know what to include in the replace/compare
submenus? This would certainly be made simpler by defaulting to and
assuming trunk/tags/branches, while also allowing users to "Select
target" for nonstandard locations. I think this falls into the minimum
level of functionality Subclipse needs to provide to be a viable
replacement for Eclipse CVS, along with the items from above.
>I think this goes beyond flexibility. These are integral features of
>Subversion. We cannot simply not support them.
Eclipse's CVS support is intuitive, powerful, and useful and covers 99%
of all CVS usage scenarios for exactly this reason: they chose not to
support everything CVS had to offer, instead providing the most common
and widest subset of functionality possible given the limitations of a
flat project environment, root-dir project files, and UI complexity and
design concerns. Why shouldn't Subclipse do the same?
Received on Tue May 10 05:13:23 2005