Thanks, that's a lot to think about,
>>> From: Les Mikesell
>Taking the history in a copy is what makes svn work and it makes any
> copied directory functionally usable as a branch or tag. But after
> that it depends on how you actually use it...
As consequence, SVN allows to create branches and tags on a part of the
software of the repository, starting at a subdirectory and the copy command
can then control/limit the scope of the branch/tag.This can be useful.
Now, I only see two uses of the command svn+copy - and two only :
- Copy the software of the repository - or a part of it - to the branches
or tags repositories,
- Restoring a removed file or directory element to the HEAD revision.
It is difficult for me to imagine a part (file or whole directory tree)
copied to another place of the same software. This would be some kind of
hardlinks (against SCM principles !).
> I don't know what I'm missing here. How is it better than explicit
> commit/update/switch operations? What happens if you are disconnected
> while making a change? What if you want your working copy to contain
> conflicts for a while before you can decide how best to resolve them?
What is nice is : you don't load and you don't update, you just see exactly
what is in the repository.
Of course, you need to be connected - with a (very) good connection to the
servers.
If connection is lost, CC is reliable enough to avoid repository corruption.
If you want to work on your side, you have to create a branch - nothing
very new.
> How well does it deal with many concurrent changes with after-the-fact
> conflict resolution?
Nothing very new again, users can always continue their work, but they have
to merge at checkin.
I think that CC and SVN are very close on this. Just that CC manages
individual checkout with reservation, and this can block the work of the
team. CC Admin have often to help in order to solve checkouts.
I think SVN is better on this point.
>>> From: Andreas Krey
> As I understand it, when you commit your stuff it also becomes immediately
> visible in all other views that look at the same branch. That is a bit
> disturbing.
Not really, this is like "The 'dirty-trunk' style" described by Les.
People write on one same branch, this works for small team (5 max).
Work is assigned to the developpers, and they should not work on the same
files - most of the time.
They have to communicate together if there is a change on some common file.
If it is a bigger team, they can use continuous integration to manage the
situation.
> Other than that, the dynamic view is an interesting tool to make
> a workspace visible on multiple machines; normally you'd either
> use NFS for that, or in 'commits are cheap and not carved in stone'
> VCS systems, you just commit and move that commit over to the target.
Yes, that is right.
> There is one thing that potentially can cause a *lot* of pain: In
Clearcase
> the views are always visible at the same path, no matter which
> branch/config spec result you're looking on. The software stored in there
> can accumulate a lot of reliance on these absolute paths over time, and
> they are hard to find during the migration.
I dont understand ?
>>> From: Andrew Reedick
> 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.
Ok, I will look more carefully to svn+log.
> 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.)
How do you lock your SVN tags, please ?
> 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*)
Nice !
> 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. :(
Compared to WC, CC snaphot views are still less efficient, because there is
still a significant interaction with the server when modifying file, for
example. No atomic checkin (to say the truth, CC adds atomic checkin
recently, this is a vob configuration, and I didn't test it - But I don't
think this is like SVN).
Now, from CC dynamic views to SVN WC, users will surely complain that they
have to load, and that they have to update.
To load 1 Gb for example in a WC could take time.
> 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.
Now, let me show you something in SVN that is disturbing for me (and other
tool, like RTC, do the same).
When you commit, commit can fail, and you might have to merge before
committing.
You merge, you did some regression tests on the merged software, and then
you finally commit.
But it just mean that the software that you store in the repository is not
strictly the software that you developped, and this software is simply lost.
This is just against the SCM principles.
Now I understand the situation, and I agree that it is enough to store the
merged result of the work.
I just want to point that no tool is perfect - no even SVN.
Atomic commit is a good idea, but there is a limit (and CC has the same
limit with individual checkout).
Thanks
Received on 2013-06-16 22:56:20 CEST