|Re: [eclipse.org-committers] Installing SVN|
so you want to be able to do 1 commit but have a commit message per file? (or set of files?) never really needed that before i just group the files per commit message and they depend on each other but if you have many different kind of changes in the same files what you want could be handy.An atomic commit requires that I can batch up numerous different commit candidates with distinct commit comments. I can't; the tooling requires a separate commit per comment.
I know of no benefit from revisioning directories, but suffer numerous pains when directories have outgoing changes (e.g. svn:ignore) while their contents have incoming changes. The default Subversive connector doesn't support folder comparison to try to understand the problem.
yes i guess eclipse, the default compare editor, doesnt have this support?I dont know the details for that editor but i could think of that it works on file contents and there isnt really one
But i agree for this the svn plugin should make there own thing.But revisioning directories is in my eyes a big plus for example that the directory has always the latest revision of the latest checkin in that dir is just perfect, in cvs you have no idea and you have to work with timestamps to get something out of it. if i look at just yesterday i commited many properties of a directory for merge support and tag support, if that must go into files like cvs that would be horrible. And then the file sits in the directory that describes the directory? i always find that weird Also i checked in numerous files all over the place but tommorrow the build manager must have those files in a build so what i just do in svn is tell him that he has to have the files of that commit revision. in CVS those files would have all there own number
they are not related.
eclipse refactor works fine at my place, yes windows explorer move shouldnt be done because you should move with the svn move commandI have yet to see SVN track a rename. A Windows Explorer move or copy is treated as delete+create. An Eclipse refactor is similarly delete+create.
But subclipse does do that just fine. Maybe you are confused because it does say A file and D file.. But the A is an A+ , the plus being with history.
I only had 1 reason that i liked more about CVS then on SVN and that was that you couldnt see in the history of a file in the trunk what revision was exactly in what build, so showing the tags. SVN by default doesnt show you the "breadcrumbs" because if you do a tagUntil the tooling works, SVN causes much more pain than joy I'm afraid. The CVS tooling is just too smooth to move on.
it is just a copy of the that revision of trunk, but trunk doesnt know that.But happily this is fixed by the subclipse plugin itself by using a special propertie that you commit on the root folder (in trunk)
Back to the top