RE: History in subversion

> From: Olivier Antoine [mailto:oliviera201304_at_gmail.com]
> Sent: Wednesday, June 12, 2013 3:42 PM
> To: users_at_subversion.apache.org
> Subject: Re: History in subversion
>
> Thanks All for your help and advices,

> 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.

You cannot directly diff two revisions of a directory, where diff is defined as diff'ing the list of file/dir objects in the directory. Instead, SVN will diff the files under the directory tree. From a CC point of view, svn file objects are first class objects with version a version tree, history, etc., whereas SVN directory objects are not. (SVN dirs are second class-ish.)

This should help you to find files and what rev they're in. '^/' is the path or svn url to check. Foo.java is the file or regex you're looking for.
        svn log -v -q ^/ | perl -ne '$r=$_ if /^r\d+/; print $r, $_ if /foo.java/;'

> 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.

If you're just trying to find a file in the current version of the repo, then "svn ls -R svn://..." You can use '-r' and peg revisions to search older revisions of the repo tree.

> 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, ..) ?

There's no such thing as a uuid or oid in SVN (or at least one that is user visible.) Instead, you can use "svn_url + revision number" or "svn_url + 'Last Changed Rev'" (which can be found via 'svn info') in order to uniquely identify a particular revision of something. 'Last Changed Rev' is preferable.

However, since SVN doesn't have true renames, 'svn copy' will normally create a new object with a new revision (aka last changed rev) number. A new revision number won't be created if you copy the parent dir the file is in. In CC parlance, instead of /repo/branches/1.0/foo.java and /repo/trunk/foo.java just being hard links to revision object #1452134521, in svn you wind up with either a new revision number:
    1. svn copy /repo/trunk/foo.java /repo/branches/1.0/foo.java
    2. svn info /repo/trunk/foo.java /repo/branches/1.0/foo.java
       ...
       Last Changed Rev: 100
       ...
       Last Changed Rev: 123
Or if you copy the parent dir, foo.java's rev number remains unchanged:
    1. svn copy /repo/trunk /repo/branches/1.0
    2. svn info /repo/trunk/foo.java /repo/branches/1.0/foo.java
       ...
       Last Changed Rev: 100
       ...
       Last Changed Rev: 100

So technically yes, SVN has the Evil Twin problem, however, it doesn't really cause problems with file merges per se, so Evil Twins aren't really a problem. Directory tree merges on the other hand, can be murder, but tree conflicts have been greatly improved in 1.7.

> Could you help more on diff dirs, please :
> - What is the best way with SVN to compare a same directory on two different branches ?

'svn diff', or checkout/export both branches (directories) and run your favorite diff tool on them. If you want to diff the contents of the dirs (i.e. the hard links,) then you can try 'svn ls -v' and diff the output (look at the rev numbers.) Generally speaking, in SVN, you don't diff directories, you diff the files in the baselines (aka branches.)

However, since SVN revisions are changesets (a collection of related changes,) you can also use 'svn mergeinfo' to "diff" two baselines/branches/directories (i.e. find what changes have not been applied from branchA to branchB.) Or you can just run the merge command to see what would get merged and then 'svn revert -R' to get back to a clean workspace (instead of checking in.) You can even do a a 'svn merge --ignore-ancestry' to merge unrelated trees (http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.nomergedata)

Long story short, if you are managing changesets between branches, then svn is quite adequate. If you're diffing code trees, then something has gone wrong with your merges and/or change management process. =)

> 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.
> 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.

It's a feature to provide maximum flexibility. The kinds of people who merge random dirs together tend to be Darwin candidates, so it's a self-correcting activity. Just merge from the root of your branch dirs, and you'll be fine. IIRC, SVN's merge tracking can now handle sub-dir merges, but in my experience, you either merge the entire baseline/branch, or you merge (cherry-pick) individual revisions (which are changesets.) There's not much reason to merge two random directories.

The only real merging landmines are 'svn merge --reintegrate' and tree conflicts. The former you can read up on (and which is going away in 1.8), the latter is poorly documented and more annoying/tedious than painful.

Teach your people to merge baselines (branch to branch) or to cherry pick revisions ('svn merge -c') and you'll be fine.

> 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.

A tag is a branch is a directory. Tags and branches aren't real objects in SVN. They're just directories that are treated as special by their human masters. Since tags are branches, it's common to use a pre-commit hook or auth file to limit write access to a tag. In practice, there's not a lot of difference between SVN checking in a change to a tag and CC moving a label to a new version on a file/dir.

>
> 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.
>
> 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.

IMHO, SVN's workspaces are light years ahead of CC's dynamic views and static workspaces in terms of ease of use. Tagging in SVN is effectively instantaneous. All of the cool stuff in CC that made for geeky CC admins isn't needed, meaning I haven't missed dynamic views, config specs, lazy branching, individual version trees, being able to cd into an element's version tree, having to merge dirs iteratively before merging files, etc., after converting to SVN. CC's slow history, slow labeling, latency issues, etc., aren't present in SVN. (However, to be fair, early versions of SVN were horrific (no merge tracking, no dir merges, etc.) but svn 1.7 is good enough outside of the --reintegrate issue.)

In other words, SVN's working paradigm is much simpler than CC's, and most of CC's super-special, gee-whiz features just aren't needed. In my experience/opinion, Subversion > ClearCase.
Received on 2013-06-12 23:33:27 CEST