subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Reedick <>
Subject RE: History in subversion
Date Fri, 14 Jun 2013 17:55:11 GMT

> From: Olivier Antoine [] 
> Sent: Thursday, June 13, 2013 3:57 PM
> To:
> 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'.

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

View raw message