Hi,
>>> From: Ryan Schmidt
> On the other hand, let's say you've made changes and tested them and try
to commit and it fails because a file is out of date.
> You wish you had made a feature branch for these changes. No problem; you
can still do it now.
> Use "svn info" on the working copy to find out what revision of trunk you
had checked out. Let's say it was 1234.
> Make a feature branch in the repository from that revision of trunk ("svn
cp $REPO/trunk_at_1234 $REPO/branches/my-feature-branch").
> Switch the working copy to that branch ("svn sw
$REPO/branches/my-feature-branch"). Commit the changes; it'll succeed.
> Now you have the state of the software you developed recorded in the
repository in the feature branch.
> Now you can continue with the task of reintegrating the feature branch
into trunk using "svn merge".
Very smart, and that seems so easy.
With CC, I'm used to create branch when the work starts, not when it is
done.
This is nice.
>>> From: Les Mikesell
> The common scenario is to have multiple 'projects' under the same
> repository root, each with their own trunk/branches/tags tree.
To be honest, I'm afraid of several projects sharing a same revision
numbering.
Repository gets bigger and bigger, problems with disk space arise, one
project wants to leave the repo,
but there is not enough space even to run svn+dump, finally a new repo is
created for the project (and the project asks to remove empty revisions ...
!).
I would prefer to create one repo per project, with one triplet of
directories trunk+branches+tags.
> 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.
Yes, I agree.
This copy mechanism, used in a raisonnable way, can be useful.
What is still confusing for me is to see that svn+annotate contains the
previous history.
Even if it is the same principle with CC for an element that is moved or
renamed.
So this is just new for me.
> So I guess you'd have to branch in the repository to match what svn does
with working copies.
Branches to isolate, or continuous integration to watch regression.
> 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.
Hum ... are these scripts "downloadable" somewhere, or do we have to write
them ... ?
> 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.
Yes, this is the solution. In CC, there is the same problem.
Thanks !
>
Received on 2013-06-17 23:09:39 CEST