From users-return-18305-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Sun Jun 16 20:56:15 2013 Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id ACA96C8D8 for ; Sun, 16 Jun 2013 20:56:15 +0000 (UTC) Received: (qmail 59851 invoked by uid 500); 16 Jun 2013 20:56:14 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 59830 invoked by uid 500); 16 Jun 2013 20:56:14 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 59823 invoked by uid 99); 16 Jun 2013 20:56:14 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Jun 2013 20:56:14 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of oliviera201304@gmail.com designates 209.85.223.195 as permitted sender) Received: from [209.85.223.195] (HELO mail-ie0-f195.google.com) (209.85.223.195) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Jun 2013 20:56:09 +0000 Received: by mail-ie0-f195.google.com with SMTP id c10so2044716ieb.6 for ; Sun, 16 Jun 2013 13:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4DdXEgsA/NdrgDpSbKSTseKGXxIScY8QwehYw06rSvI=; b=gMNrNwJwslO2+uObWB9saKvmqxDc4YQSBdmcogsw2ANg5cZAn+NqwnDlKmRFbrUfuJ gOiof2rvXqIrY+Bc2vq1cOfEAWB+LjRlHKBf4qHuGEDQuyHp8GAmLN9HVwo/wagiwWmG 5MGwTsSmpVFao/A6XiMAkZpzCuCwdnmXTvrtYjf2bUS9BLwMgYOhH9tTf/mm4uHeXLn0 ggZ/1U/crXclOSpJVKE03RQjPd66jMuqkLsYPXZkSXyKVoj270ZmPNN97HCkiuiZKEmL UVc723pIt0BOTv13e/ToE/FTUzkUg4wsyypznDfVj+x0F67r2BRsso7z1ajZHTslg2hk IiYQ== MIME-Version: 1.0 X-Received: by 10.50.43.162 with SMTP id x2mr3346215igl.94.1371416148985; Sun, 16 Jun 2013 13:55:48 -0700 (PDT) Received: by 10.64.147.67 with HTTP; Sun, 16 Jun 2013 13:55:48 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 Jun 2013 22:55:48 +0200 Message-ID: Subject: Re: History in subversion From: Olivier Antoine To: users@subversion.apache.org Content-Type: multipart/alternative; boundary=089e0103e4ce664d7b04df4bb449 X-Virus-Checked: Checked by ClamAV on apache.org --089e0103e4ce664d7b04df4bb449 Content-Type: text/plain; charset=ISO-8859-1 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 --089e0103e4ce664d7b04df4bb449 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks, that's a lot to think about,

&= gt;>> From: Les Mikesell

=A0>Taking the history in a copy i= s what makes svn work and it makes any
> copied directory functionall= y usable as a branch or tag.=A0 But after
> that it depends on how you actually use it...

As consequence, S= VN allows to create branches and tags on a part of the software of the repo= sitory, starting at a subdirectory and the copy command can then control/li= mit 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=A0 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 h= ardlinks (against SCM principles !).

> I don't know what I= 9;m missing here.=A0 How is it better than explicit
> commit/update/switch operations?=A0 What happens if you are disconnect= ed
> while making a change? What if you want your working copy to con= tain
> conflicts for a while before you can decide how best to resolv= e 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 conne= cted - with a (very) good connection to the servers.
If connection is lo= st, CC is reliable enough to avoid repository corruption.
If you want to work on your side, you have to create a branch - nothing ver= y 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 indivi= dual 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 b= etter on this point.


>>> From: Andreas Krey

> As I understand it, whe= n 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" de= scribed by Les.
People write on one same branch, this works for small te= am (5 max).
Work is assigned to the developpers, and they should not wor= k 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 interest= ing 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 ston= e'
> VCS systems, you just commit and move that commit over to th= e target.

Yes, that is right.

> There is one thing that potentially can= cause a *lot* of pain: In Clearcase
> the views are always visible a= t 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, an= d
> they are hard to find during the migration.

I dont underst= and ?


>>> From: Andrew Reedick

> Because in S= VN, you're normally working in a workspace and not directly in the repo= sitory.=A0 'svn log' is your 'ct find' in most cases.=A0 > Plus, in SVN you're working in a workspace most of the time and th= e 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 comman= ds.=A0 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 wil= l look more carefully to svn+log.

> SVN does that.=A0 But instead of applying labels to each element, = svn simply makes a complete copy (i.e. cp -pr branch1.0 tags/REL_1.0).=A0 <= br>> 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.=A0 And then locking the REL1.0 branch so = folks don't check into it.=A0 (But SVN's branching/tagging is very = efficient and fast.)

How=A0 do you lock your SVN tags, please ?
<= br> > You can get the link back to the branch point via 'svn log --stop-= on-copy -v -r 1:HEAD -l 1'.=A0 (But there is an edge case which breaks = that,
> requiring iterative use of 'svn log --stop-on-copy'.= =A0 *grumble*)

Nice !

> Back in my day, CC snapshot views were terrible/horr= ible/nearly_unusable.=A0 SVN workspaces are simply great.=A0 I doubt your u= sers will complain
> once they start using them.=A0 IME, the only do= wnside to SVN workspaces/snapshots is that developers will whine about havi= ng to checkout a full
> directory tree no matter how small the tree.=A0 'svn switch' h= elps reduce the need to checkout full workspaces, but it still doesn't = reduce the whining though.=A0 :(

Compared to WC, CC snaphot views ar= e still less efficient, because there is still a significant interaction wi= th the server when modifying file, for example. No atomic checkin (to say t= he 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 t= hey have to load, and that they have to update.
To load 1 Gb for = example in a WC could take time.

=A0> Yes, but in practice, = you don't really need real time access to a repository.=A0 In SVN, you = do your work, then when you're ready, you run 'svn update' to p= ull
> in other people's changes.=A0 Meaning, you decide when to take cha= nges 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.=A0 It's why hooks ar= e server side
> only (instead of client side hooks,) why workspaces are "snapshot= s" instead of dynamic views, why svn URLs are URLs, etc.


No= w, let me show you something in SVN that is disturbing for me (and other to= ol, like RTC, do the same).

When you commit, commit can fail, and you might have to merge before co= mmitting.
You merge, you did some regression tests on the merged softwar= e, 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 developpe= d, and this software is simply lost.
This is just against the SCM principles.

Now I understand the situat= ion, and I agree that it is enough to store the merged result of the work.<= br>I just want to point that no tool is perfect - no even SVN.
Atomic c= ommit is a good idea, but there is a limit (and CC has the same limit with = individual checkout).

Thanks
--089e0103e4ce664d7b04df4bb449--