subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Reedick <Andrew.Reed...@cbeyond.net>
Subject RE: History in subversion
Date Wed, 12 Jun 2013 21:32:05 GMT


> From: Olivier Antoine [mailto:oliviera201304@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.



Mime
View raw message