RE: History in subversion

> From: Olivier Antoine [mailto:oliviera201304_at_gmail.com]
> Sent: Thursday, June 13, 2013 3:57 PM
> To: users_at_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.
Received on 2013-06-14 20:04:03 CEST