"Charles Nutter" <cnutter@ventera.com> wrote on 05/09/2005 03:13:23 PM:
> 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
> specified
> >module name" and enter "Project/trunk". It is important that trunk not
>
> >exist already.
>
> 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?
Yes, I think it is reasonable. I just think that the Subversion mkdir
command ought to support it so that it can be done in a single commit
instead of several. Someone was working on this feature in Subversion so
I was hoping it would make it's way into 1.2 -- I do not think it did.
Do you have your Console view turned on and showing? What errors do you
see when you do this?
> 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?
I think that Subclipse already does a lot of this.
> 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.
This is the third time in this message you have said the same thing. I
get it, and I answered it in the previous message and again in this one. I
agree that is how it should work. We are currently waiting for a
Subversion API enhancement to enable it. We could do recursive commits, I
just do not want to do that if we do not have to.
> 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.
The Eclipse team is also a paid team of IBM employees. Subclipse is just
a handful of volunteer contributors. Join the project and contribute some
code, or recruit someone else to if you cannot. Or lobby the Eclipse team
to pitch in.
> 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.
I am sorry but you are obviously just new to Subversion. These are
recommendations but what do we tell all of the people who do not want to
follow them? The Subversion project doesn't really follow it, neither
does this project, neither does TortoiseSVN. We cannot force a structure
on anyone.
> 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.
Agreed, but I do not think that factors into this equation all that much.
> 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.
I think we are well aware of the limitations you have to deal with when
working in an IDE in order to conform to the rules of that IDE. We do a
great job with that already. I do not think we have to force a specific
repository structure on users to do that.
> 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.
These nodes are fairly top level, I do not understand why you cannot
expand the folder to what you want and then checkout your project.
> 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?
Yes you are. This is just a fundamental difference between Subversion and
CVS. We cannot really change that. Look at the Subversion users@ list
archives. This issue is constantly talked about. I think that our
support for tagging and working with branches is already very good,
provided that you know how to work with these features in Subversion.
> 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 we would have to have a UI that allows you to select the target
you want to compare with. The biggest problem is that the only way we can
do this compare is to pull down the whole branch and then let Eclipse do
the compare. Ideally we could let Subversion tell us the differences
(which it can do quickly) and then feed that to the Eclipse compare engine
to give you a nice display of the differences. Short of that, you might
as well just checkout the branch and use Eclipse's compare with -> each
other feature.
> 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?
I think Subclipse is pretty good too.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Tue May 10 05:32:58 2005