Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of lesmikesell@gmail.com
 designates 209.85.212.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ8prHXHk1YifAu2seL_FMU3374vfSB2TStAWEHyAJ-pbSW9Pw@mail.gmail.com>
References: 
 <CAJ8prHVG8W0g8hfXw6CwEf+GHGff3aUN65sxTFLQMoCJSSFrOQ@mail.gmail.com>
	<CAJ8prHXHk1YifAu2seL_FMU3374vfSB2TStAWEHyAJ-pbSW9Pw@mail.gmail.com>
Date: Sun, 16 Jun 2013 23:34:56 -0500
Message-ID: 
 <CAOAgVpzRKiZ8vnYo8Tm9=4qCetjh+nNDGy+4QC4rD09SFxbraA@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 Sun, Jun 16, 2013 at 3:55 PM, Olivier Antoine
<oliviera201304@gmail.com> wrote:
>
>  >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.

The common scenario is to have multiple 'projects' under the same
repository root, each with their own trunk/branches/tags tree.

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

Once you have copied it, it goes its own way but retains previous
history - there is nothing wrong with that.  Consider a library that
evolves as a component of some other project, but you subsequently
realize it can be used in several programs that will be maintained
separately.  It might make sense to copy it up to its own top-level
project where it can more sensibly have its own release schedule with
its own branches and tags to easily support multiple versions
concurrently being used by different things.

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

But - I don't like surprises...  And I might have temporary local
changes in my copy, or have intentionally set up a working copy with
mixed revisions.   So I guess you'd have to branch in the repository
to match what svn does with working copies.

> How  do you lock your SVN tags, please ?

You can use hook scripts for that.   We sometimes check out source
from tags and commit the resulting binaries back - not exactly 'clean'
but pragmatically useful - and possible with an appropriate script
that allows this exception.

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

If you have concurrent work going on, it is usually best to update
before and after your commit.  And you'll resolve conflicts in the
updates.

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

If you want to store all copies of concurrent work instead of just the
the way you resolved your updates, you need to be working on separate
branches with later resolution.   That's the 'feature branch' style
and there are sometimes reasons to use it, even though there is some
extra overhead.   But regardless of the process, you eventually have
to resolve conflicting changes.

-- 
   Les Mikesell
     lesmikesell@gmail.com