Perhaps a difference between Eclipse 3.0 and 3.1? I am not using 3.1.
- Charlie
-----Original Message-----
From: Alexander Kitaev [mailto:alex@tmate.org]
Sent: Tuesday, May 10, 2005 10:01 AM
To: users@subclipse.tigris.org
Subject: RE: More on importing large project, layout of
projects/versions/branches in repository
Hello Charles,
I just repeated your steps with JavaSVN ("trunk" version), Subclipse
0.9.30, Subversion server at http://localhost:8080/svn/ - it all works
fine, just as expected.
I'm using Windows XP SP2, Eclipse 3.1M6
Alexander Kitaev,
TMate Software,
http://tmatesoft.com/
> -----Original Message-----
> From: Charles Nutter [mailto:cnutter@ventera.com]
> Sent: Monday, May 09, 2005 9:57 PM
> To: users@subclipse.tigris.org
> Subject: RE: More on importing large project, layout of
> projects/versions/branches in repository
>
> The issue is detailed below. This is with current Eclipse
> 3.0, Subclipse, JavaSVN all on Windows and 1.1ish Subversion
> on Gentoo Linux.
> Same result on two different machines using both https and
> svn+ssh protocols. I have not tried without JavaSVN (because
> I want to use svn or svn+ssh protocols).
>
> Steps to reproduce:
>
> 1. Create project dir in SVN using Subclipse (XXX for
> example) 2. Team => Share Project, as "XXX/trunk"
> 3. Share appears to work, Synchronize view is brought up 4.
> Right click root of sync view, Commit...
> 5. Enter comment, "Select All" resources to commit, and hit
> Ok 6. Following error results:
>
> Error May 09, 2005 14:47:31.298 The SVN synchronization
> information for {0} has become corrupt or does not exist.
>
> An exception stack trace could not be found. No output is
> seen on the console (with console output turned on).
>
> Some problem with the initialization of the local project
> when adding it, perhaps?
>
> - Charlie
>
> -----Original Message-----
> From: Mark Phippard [mailto:MarkP@softlanding.com]
> Sent: Monday, May 09, 2005 2:33 PM
> To: users@subclipse.tigris.org
> Subject: RE: RE: More on importing large project, layout of
> projects/versions/branches in repository
>
> "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.
> ______________________________________________________________
> __________
> _____
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Wed May 11 03:10:36 2005