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



Reply via email to