Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of lesmikesell@gmail.com
 designates 209.85.128.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ8prHXpTTRbhSUiauCCZx3e_YOBXX=jgFapbGDVqQh=iH5NkQ@mail.gmail.com>
References: 
 <CAJ8prHVG8W0g8hfXw6CwEf+GHGff3aUN65sxTFLQMoCJSSFrOQ@mail.gmail.com>
	<CAJ8prHXpTTRbhSUiauCCZx3e_YOBXX=jgFapbGDVqQh=iH5NkQ@mail.gmail.com>
Date: Thu, 13 Jun 2013 16:23:39 -0500
Message-ID: 
 <CAOAgVpzW-yqkg==svxr6t+yw7gkew=GTuFdZcq2PH5GdW+UooA@mail.gmail.com>
Subject: Re: History in subversion
From: Les Mikesell <lesmikesell@gmail.com>
To: Olivier Antoine <oliviera201304@gmail.com>
Cc: Subversion <users@subversion.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 13, 2013 at 2:57 PM, Olivier Antoine
<oliviera201304@gmail.com> wrote:
>
> A good SCM principe is :
> - to create tag on branch
> - to create branch from tag
>

I think most people settle on one of two basic 'styles'.   The
'dirty-trunk' style makes the most sense to me where most development
happens on the trunk with development branches only happening for
disruptive or experimental changes.   As the trunk approaches a new
release point, you make branches for testing and final development and
tags for any revisions you want to be able to recreate.  Before
merge-tracking worked well this minimized the amount of merging since
everything progresses in the same direction.  It also encourages
developers to take advantage of each others changes and sort out
conflicts early - and it lets you maintain multiple releases
concurrently on their own branches.

The other approach keeps the trunk stable and always usable by using
'feature branches' for all new work, merging back to trunk after
completion and testing as a form of release management.   Of course
you can mix/match styles as appropriate for your workflow.

> The two most complex commands for SVN seems to be svn+copy and svn+merge,
> Thanks for your explaination on svn+copy, it helps, because I was surprised
> to see how svn+copy duplicates history.

That's pretty much the point of it...

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

Just remember that svn tracks the 'copied from' history so it can do
sensible things when merging, updating, diffing, etc., objects with
common ancestry.  It doesn't track the 'copy to'.

> These are raisonnable SCM principles, don't you think ?

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

> Revision numbers can be renumbered one day in the repository, so they cannot
> be used in the SCM process, am I wrong ?

No, revisions can never be renumbered in an existing repository.   It
is possible to dump the repository and load the history into a
different one and change the revision numbers in the process, but that
is a drastic administrative decision that will invalidate all
checked-out workspaces.   But, this eventual possibility is one of the
reasons that you want your own human-friendly branch/tag names for the
revisions you will always want to be able to find.

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

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?

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

How well does it deal with many concurrent changes with after-the-fact
conflict resolution?

--
   Les Mikesell
     lesmikesell@gmail.com