> From: Olivier Antoine [mailto:oliviera201...@gmail.com]
> Sent: Wednesday, June 12, 2013 3:42 PM
> To: users@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.
