[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: MERGE: Command Line Results Different from TortoiseSVN Results

From: Marcia Almeida Rocha <Marcia.Rocha_at_wedotechnologies.com>
Date: Fri, 16 Jan 2015 10:14:02 +0000

Thanks Gavin

I know that we can create a new branch based on any version and not just based on HEAD, but many times, they have many revisions under trunk and not sequentially are approved, so the idea was created the stable branch at the first moment ,empty and they are doing merge to there just from revisions that are good.

Since all previous versions are kept alive I think, as we have always 2 branches by version( work branch and stable branch), we will remove the trunk idea and we will have just 1.0-work, 1.0, 2.0-work, 2.0....
And the first 1.0 stable will be created at the start of project, based on 1.0-work, empty.

When 2.0 starts, we will create 2.0-work based on 1.0-work and we will create the stable branch 2.0 based on 2.0-work and we will consider that all previous revisions from 1.0-work are already ok to 2.0 ,so we already will create stable branch 2.0 based on this 2.0-work.

Do you think is it bad idea remove trunk?

Thanks by your ideas, but If it is possible to change TSVN to have the same behaviou than command line for my initial problem, it would be good:)

Thanks
Best Regards
 

Marcia Rocha -Tech Support Team
Tel. + 351 939650228
marcia.rocha_at_wedotechnologies.com
www.wedotechnologies.com

-----Original Message-----
From: Gavin Lambert [mailto:colnet_at_mirality.co.nz]
Sent: 15 de janeiro de 2015 23:32
To: users_at_tortoisesvn.tigris.org
Subject: RE: MERGE: Command Line Results Different from TortoiseSVN Results

On 16/01/2015 12:09, Marcia Almeida Rocha quoth:
> Thanks Gavin, but I cannot implement your suggestion, because the
branch 1.0 correspond just the revisions approved from 1.0-work , so sometimes they have to do commit under 1.0-work but not all are approved to merge to 1.0, and I cannot create 1.0 based on 1.0-work.
>
> The another suggestion to merge from 1.0-work to trunk and trunk to
1.0, it is not applicable too, because when I have 1.0-work, it means that trunk is the "work" branch for the new version (2.0 for example), so changes from trunk cannot be merged to 1.0 but just to 2.0, since trunk has in that moment changes to the new version.

Neither of those are a problem. Just specify specific revisions to be merged. (Although normally you'd want all 1.0-work to end up in trunk as well, so that 2.0 doesn't reintroduce bugs fixed in 1.0.)

Presumably at some point when there is only trunk existing, you are stating "ok, trunk is good now, I want to freeze everything for 1.0". You then immediately create 1.0-work from trunk and 1.0 from 1.0-work at that instant. Thereafter devs commit to either trunk or 1.0-work or both as needed, and you can cherry pick the commits from 1.0-work to 1.0 as they are approved.

The same process should work for 2.0. Also remember that when you create the stable branches you don't have to pick the current HEAD of trunk -- you can create it from the last revision you're fully happy with if you like, and then start cherry-picking further revisions from there.

Just remember to individually commit revisions merged from trunk to 2.0-work if you want to be able to individually merge them to 2.0 instead of as a bundle.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3094345

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3094352

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-01-16 11:14:34 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.