svn merge [source svn location] -c 444,469,480
> -Original Message-
> From: emerson [mailto:echofloripa.y...@gmail.com]
> Sent: 05 July 2010 17:38
> To: Andy Levy; users@subversion.apache.org
> Subject: Re: Applying multiple commits done to a branch to
> another bra
Hi
I was told that I could use the following syntax to merge different
revisions at once:
svn merge [source svn location] -c 444 -c 469 -c 480
However, when I tried using this syntax I found out that all merges
are done against the initial state of the current folder which
resulted in conflicts,
On Thu, Jun 17, 2010 at 05:38, emerson wrote:
> Hi Guys
>
> Thanks for the answers.
> First Andy, yes, we put more than the story code on the commits :)
> We are using svn 1.4.4 ont he server, so to be able to keep track of
> the ancestors logs we will probably need to upgrade.
Note that the 1.4
Hi Guys
Thanks for the answers.
First Andy, yes, we put more than the story code on the commits :)
We are using svn 1.4.4 ont he server, so to be able to keep track of
the ancestors logs we will probably need to upgrade.
Still, I believe we need some tool to search the logs for that
especific #xx
On Thu, Jun 17, 2010 at 4:20 AM, Bob Archer wrote:
>
>> You're describing a normal usage of merging.
>> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html
>>
>> You don't want to redo all those commit messages, you want the merge
>> to be aware of the history behind everything that's been
On Wed, Jun 16, 2010 at 14:20, Bob Archer wrote:
>
>> You're describing a normal usage of merging.
>> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html
>>
>> You don't want to redo all those commit messages, you want the merge
>> to be aware of the history behind everything that's been d
> You're describing a normal usage of merging.
> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html
>
> You don't want to redo all those commit messages, you want the merge
> to be aware of the history behind everything that's been done (which,
> if you're using 1.5 or later, is taken c
Hi
We are moving from a single trunk to a layered approach, with a
unstable (same as the old trunk), and a stable branch. The code should
be promoted to the stable branch only when a certain story would be
done (finished and tested).
When creating the story, several commits might had been necessar
Hi
We are moving from a single trunk to a layered approach, with a
unstable (same as the old trunk), and a stable branch. The code should
be promoted to the stable branch only when a certain story would be
done (finished and tested).
When creating the story, several commits might had been necessar
On Wed, Jun 16, 2010 at 14:06, emerson wrote:
> Hi
>
> We are moving from a single trunk to a layered approach, with a
> unstable (same as the old trunk), and a stable branch. The code should
> be promoted to the stable branch only when a certain story would be
> done (finished and tested).
> When
Hi
We are moving from a single trunk to a layered approach, with a
unstable (same as the old trunk), and a stable branch. The code should
be promoted to the stable branch only when a certain story would be
done (finished and tested).
When creating the story, several commits might had been necessar
11 matches
Mail list logo