>
>
>
> > One further point on this is that the merge function in subclipse doesn't
> work across projects in eclipse (where the eclipse projects are all within
> one trunk/branch). Again, this makes merge pretty unusable.
>
> You just described the structure of every project I've ever worked on.
> Not only is merge not unusable, I think it works great. I've never
> had a problem doing this, even before merge tracking.
>
>
>
>
i do agree with stephen on this one.
We also have this:
trunk/project1
trunk/project2
and the same 2:
branch/v21/project1
branch/v21/project2
now i do a commit that spans over the 2 in the branch and i do want to merge
that (i use the collab merge client)
then that is 2 actions (and the merge client still have some usability
issues to be really speedy..)
I guess what i need to do is check out the /trunk and the branch/v21 folder
and then import the projects from the folders as eclipse projects
This didnt work quite well sometime ago but i think that is fixed
But the other question is if i do that. And i merge on the folder above the
projects
and i commit there the i do also commit the svn properties to that dir. What
happens then if another one does it on the project level?
Then he doesnt see those properties i guess?
Same for the branches/tags configuration. If i would commit that only on the
projects parent dir. Would i still see the branch/tag in the history view?
In other works does it go up the tree far enough to look for that kind of
information or does it stop at the project level (what is a project in
eclipse)
(I could say exactly the same for example on the bug traq svn properties.
Can i commit that on 1 top level dir what is not direct THE project in
eclipse where i work on?)
johan
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2353813
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2009-05-26 16:12:07 CEST