On Wed, Jun 12, 2013 at 2:41 PM, Olivier Antoine
<oliviera201304_at_gmail.com> wrote:
> >
> Ok, svn log -v will help,
>
> But :
>
> With CC, I can easily search for any file element in a repository, and
> directly get its path,
> With SVN, I have to check all revisions, then I can know where this element
> is located in the repository (maybe several locations), I can find in which
> revision it was removed.
> This is double manual search.
That's not what most people do with subversion most of the time...
There is a tool called fisheye:
http://www.atlassian.com/software/fisheye/overview
that will maintain a full-text search index and track a bunch of stats
if you need real search capability.
> When users ask for help, I have to go in their repository that I don't know
> at all, users often give less than half the information I need to locate the
> file where they need help.
> With CC, I can quickly analyze a repository, and get easily the missing
> information.
> With SVN, I feel like blind, because I cannot do the same analysis on the
> repository. I cannot do a global search, I have to check the revisions
> individually.
Agreed, it works better if you know where you put the things that
you'll want back.
> About peg revision :
> Peg revision means that I can access any file and directory "version"
> without checkout, this is already a nice help.
> But : is there also an individual identifier for directory and file (uuid,
> oid, ..) ?
The revision number is global for every object in the repository and
changes atomically with each operation. So you can use a peg revision
with any path element to make it a unique identifier.
> Could you help more on diff dirs, please :
> - What is the best way with SVN to compare a same directory on two different
> branches ?
Just check one out and diff the workspace against a different revision
or branch path or both.
> I am very confused by many things with SVN, one of them is :
> - I can merge from any directory to any directory anywhere, and I just get a
> terrible Tree conflict.
Well, if that's not what you want, don't do that... Or revert when you
see it is wrong. A lot of things will make more sense if you
understand that subversion just manages arbitrary directories and the
revision histories of them and the files contained there. Copying a
directory takes that history along, so you can use directory copies as
branches and tags, but it is entirely up to you to set up and follow
your own conventions of where they are and what they are named.
Subversion doesn't really care where the copy goes or whether you
subsequently try to merge from somewhere else, but if the histories
don't have much in common a merge probably isn't going to make sense.
> With CC, the merge is inside the version tree of the file or directory
> element. This kind of mistake is not possible.
> I don't understand why it is done like this with SVN.
Subversion doesn't know/care where in the tree you put what you want
to call a project. Sometimes that is a good thing.
> I did not understand everything with branches and tags, I have to read again
> the manual, but I have the feeling that branches and tags are not linked,
> this is strange to me.
Linked to what? Think of them as 'cheap copies' of whatever they are
copied from. And remember that subversion doesn't really know or
care that they are branches or tags - that's your convention and if
you follow it everything works fine.
>> To re-emphasize, I'm very serious about the need to stop trying to apply
>> CC paradigms to SVN. It's frustrating, and, in my experience, the CC way of
>> doing things didn't provide significant advantages in (or over) SVN.
>
> I understand, and I don't try to use SVN "in the CC way". SVN and CC are
> tools, the goal for me is the software configuration management of the
> projects,
> and also to be able to help the users of the tools in the best way.
The 'best' way isn't necessarily the same for everyone, but you do
need to understand that subversion doesn't force any usage style or
layout so it is important to have and follow conventions.
> On the other hand, I'd like to understand and compare the capabilities of
> both tools by myself, because what I read in the past was not detailed
> enough in my opinion.
Have you read "The" book: http://svnbook.red-bean.com/ ? If you
have, try again to get a better understanding of what subversion
operations are inherent in the server/repository and what are just
conventions or client-side concepts. The idea of merge-tracking does
make this part a little fuzzy.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2013-06-12 22:45:34 CEST