From: Olivier Antoine [mailto:oliviera201...@gmail.com]
Sent: Thursday, June 13, 2013 3:57 PM
To: users@subversion.apache.org
Subject: Re: History in subversion
Thanks All again for your help,
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.
Yes, I started a short perl script for this, but this is strange that nobody
asked for a svn+find command (IMO).
Because in SVN, you're normally working in a workspace and not directly in the
repository. 'svn log' is your 'ct find' in most cases. Plus, in SVN you're
working in a workspace most of the time and the normal command line tools (e.g.
find, dir /s) work just fine, so there's not much need to re-create the wheel
with SVN equivalent commands. You need 'ct find' because all the history is
tracked in each individual element, whereas in SVN, history is contained in
each (global) revision.
In other words, you're probably trying to apply CC paradigms to SVN.
Tree conflicts seem to be very mysterious. Why is there a such issue in SVN
and not CC - what to think about this, please ?
Directory merging wasn't in the initial design architecture of SVN... It's
been added in bits since 1.4(?) and hasn't really gotten good until 1.6/1.7.
And of course : Is it possible to do refactoring on any branch, and to merge
to any branch without trouble ?
Mostly. Again you have to deal with the limitations of 'merge --reintegrate'
in 1.7.x (which goes away in 1.8.)
If you are merging unrelated code (i.e. no common ancestor) then you're asking
if SVN can merge Evil Twins. I think the answer is mostly yes, but I could be
wrong because it's rare that I encounter that situation.
Ideally, your branches have a common ancestry in order to make merge conflict
resolution easier. You can ignore ancestry to merge unrelated trees, but if
you find yourself merging often between unrelated (i.e. no common ancestor)
branches, then I would hazard to say that there's something wrong with your
branching process and/or baseline management (i.e. barring an exceptional use
case, you might be using SVN incorrectly or working against SVN's branching
paradigm?)
Like I said above, I wish to continue :
- to create tags on branch (and to keep the link of the tag with the branch)
- and to create a branch from a tag (and to keep the information that the
branch starts from this tag).
These are raisonnable SCM principles, don't you think ?
SVN does that. But instead of applying labels to each element, svn simply
makes a complete copy (i.e. cp -pr branch1.0 tags/REL_1.0). In CC terms, it's
conceptually similar to adding '-mkbranch REL1.0' to a config_spec and doing a
checkout/checkin on each element to create the REL1.0 branch. And then locking
the REL1.0 branch so folks don't check into it. (But SVN's branching/tagging
is very efficient and fast.)
You can get the link back to the branch point via 'svn log --stop-on-copy -v -r
1:HEAD -l 1'. (But there is an edge case which breaks that, requiring
iterative use of 'svn log --stop-on-copy'. *grumble*)
I think that dynamic view is still a nice concept. Dynamic views is something
that users like much, and they desespair when they have to migrate to
snapshot views.
You create your view, you have an (almost) real-time connection to the
repository, your view is available immediatly on all the machines.
The working copy needs to be loaded, recreated and reloaded on each machine.
Back in my day, CC snapshot views were terrible/horrible/nearly_unusable. SVN
workspaces are simply great. I doubt your users will complain once they start
using them. IME, the only downside to SVN workspaces/snapshots is that
developers will whine about having to checkout a full directory tree no matter
how small the tree. 'svn switch' helps reduce the need to checkout full
workspaces, but it still doesn't reduce the whining though. :(
But I never saw another tool with these principles : real-time access to
repository, build based on version (not on time), winkin, configuration
audit, SCM process level (stream, baseline, component), multisite.
Yes, but in practice, you don't really need real time access to a repository.
In SVN, you do your work, then when you're ready, you run 'svn update' to pull
in other people's changes. Meaning, you decide when to take changes instead of
having random changes spontaneously appear in your view.
It helps to remember that SVN was designed to support open source projects with
developers spread across the world. It's why hooks are server side only
(instead of client side hooks,) why workspaces are snapshots instead of
dynamic views, why svn URLs are URLs, etc.
