Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Subversive » Branching/Merging workflow ideas
Branching/Merging workflow ideas [message #502884] Thu, 10 December 2009 08:05 Go to next message
Chris Lercher is currently offline Chris LercherFriend
Messages: 14
Registered: December 2009
Junior Member
Hi,

I'd like to discuss some ideas here about what I imagine the ideal workflow of branching/merging in subversive could look like. I'm very interested in your opinions, ideas and suggestions - or if you agree with me on this at all!

Let's say we start out with a new set of related Eclipse projects. We decide on the following structure in our subversion repository:

demo/trunk/demo-ui
demo/trunk/demo-model


Our workspace looks like this:
demo-ui [Trunk: demo-ui]
demo-model [Trunk: demo-model]


Now here's my typical workflow: Someone checks in some code, while I also edit some classes. From time to time I use "Team->Synchronize with repository" to keep up to date. In order to not accidentally destroy my unfinished work, I don't perform a "Team->Update" - because this may load some "non-conflicting" changes into my workspace. I wrote "non-conflicting" in quotes, because "syntactically non-conflicting" unfortunately doesn't always mean "semantically non-conflicting".

The synchronize view shows me very nicely, which updates I haven't yet integrated into my code. Now I can go into any of the files with incoming changes, and use a "Copy from right to left" to get some individual changes. This means especially: I don't have to do a "Copy ALL changes from right to left", and I don't yet have to mark my file as merged! I'll just leave my files half-merged, which works because the Synchronize view will know, which parts in my file aren't merged yet.

Now I can run a debugger, write some unit tests, and see, if my changes work together with the new changes I just applied. The point is here: The synchronize view doesn't put any diff conflict markers in my files, so I can compile and run them. This is IMO one of the outstanding features of Eclipse, which I wouldn't have if working on the command line.

I can repeat this cycle as often as I want. When I'm finally finished, I can go into the synchronize view again (and refresh it), befor I finally commit.

- - - Smile
Up to this point, everything is great. But now our team member Harry wants to implement a fancy feature, and we're all not sure, if we're going to integrate that feature in the next version (or at all). So we decide, that this feature will be implemented in a feature branch. Now our repository looks like this:

demo/trunk/demo-ui
demo/trunk/demo-model
demo/branches/fancy1/demo-ui
demo/branches/fancy1/demo-model

Harry copied both demo-ui and demo-model, because both will have to be changed for that branch. (In other cases maybe only the demo-ui would be copied).

Harry creates a new workspace that looks like this:
demo-ui [Branch: fancy1]
demo-model [Branch: fancy1]


(We usually take the "separate workspace for each branch" approach, so Harry can still work on the trunk while he's working on his fancy feature.)

A few weeks later, Harry cheers "I did it!", and I know immediately, what this means for me: I'll be the one who will have to reintegrate his feature into trunk. So first I finish my own work and check it in. Then I use Subversive's "Team -> Merge -> Reintegrate" capability.

So what I would expect here, is that this works exactly like my usual "Team -> Synchronize" workflow. But it doesn't.

1. The smaller issue: I must navigate to the branch manually using an absolute path. It would be extremely nice, if I just had to select "fancy1" instead of "http://server1.lan/subversion/demo/branches/fancy1/demo-ui". Especially because I'll have to do the same thing again for the demo-model. I know, that these things are a little bit complex, because subversion's branch layout is just a little bit too flexible: Single-project layout, and multi-project layout, and trunk/branches/tags at top level of repository or not. But I see that Subversive already has some kind of support for these layouts (very nice!), so why not use them here?

2. The bigger issue:

I can't perform the workflow that I usually use with "Team -> Synchronize". I can't use a Synchronize view that shows me, which changes I already accepted, and which ones are still "to do". Also, because I get diff conflict markers in my files, I can't debug, and I can't run unit tests until I have merged everything from the 75 files that Harry changed.

So the only thing I can do at this point is to accept all his changes, and then do a "Team -> Synchronize" against trunk. But this creates two problems:

- It gets complicated, if someone else continues to check things in to trunk (I'd probably better do a "Team -> Switch" to the current revision number first).
- Accepting all of Harry's experimental changes first, and then undoing only some of them is much more dangerous than first accepting none, and then accepting changes bit by bit. The thing to keep in mind here is: I don't want to bash Harry, but If the changes weren't experimental and potentially dangerous in nature, we wouldn't have created a separate feature branch in the first place!

Now of course we could argue: "But you don't get this kind of workflow with the command line svn client either". And while that's true, this would also be true for the usual "Team -> Synchronize" workflow...

I have no idea, what the status is on this - if that's already planned for Subversive, or if other people even want that? What do you think? Do you have similar workflows - or would you suggest a better one?

Chris

[Updated on: Thu, 10 December 2009 08:29]

Report message to a moderator

Re: Branching/Merging workflow ideas [message #503464 is a reply to message #502884] Mon, 14 December 2009 10:52 Go to previous messageGo to next message
Igor Burilo is currently offline Igor BuriloFriend
Messages: 435
Registered: July 2009
Senior Member
Hello Chris,

Thanks for sharing your opinion about branching/merging. Please, see my
comments below.

1.
> The smaller issue: I must navigate to the branch manually using an
> absolute path. It would be extremely nice, if I just had to select
> "fancy1" instead of
> "http://server1.lan/subversion/demo/branches/fancy1/demo-ui". Especially
> because I'll have to do the same thing again for the demo-model. I know,
> that these things are a little bit complex, because subversion's branch
> layout is just a little bit too flexible: Single-project layout, and
> multi-project layout, and trunk/branches/tags at top level of repository
> or not. But I see that Subversive already has some kind of support for
> these layouts (very nice!), so why not use them here?

In Merge dialog there's a Browse button, which allows you to easily select
the URL, also it's smart enough to open Select Resource dialog on needed
place, for example, if I work in branch:
http://localhost/repos/first/ProjectsData/Subversive/Project -Foo/branches/br1
and when I press Browse button, Select Resource dialog is opened on
http://localhost/repos/first/ProjectsData/Subversive/Project -Foo and it
would be very easy for you to select a needed branch.
Also URL field is a combo box which remembers previously entered values, so
if you previously made merge for 'demo-ui' you can simply select it from
combo and change 'demo-ui' to 'demo-model'.
Probably, we could list branches/tags for particular project but you can
merge not only from branches/tags, you can merge from any place in
repository, also you may not follow branches/tags structure, so it's not a
universal solution, it'll just complicate UI.

2.
> I can't perform the workflow that I usually use with "Team ->
> Synchronize". I can't use a Synchronize view that shows me, which changes
> I already accepted, and which ones are still "to do". Also, because I get
> diff conflict markers in my files, I can't debug, and I can't run unit
> tests until I have merged everything from the 75 that Harry changed.

SVN recommends following workflow for branching/merging:
- if you plan to make many changes or these changes are time intensive for
adding new functionality, you need to create a feature branch. This is what
you exactly did and this is good.
- there may be a big challenge to merge changes from the branch back to the
trunk. That's your case. Here's a solution to it proposed by SVN:
"This situation is best avoided by regularly merging trunk changes to the
branch. Make up a
policy: once a week, merge the last week's worth of trunk changes to the
branch.
At some point, you'll be ready to merge the "synchronized" feature branch
back to the
trunk. To do this, begin by doing a final merge of the latest trunk changes
to the branch.
When that's done, the latest versions of branch and trunk will be absolutely
identical except
for your branch changes. You would then merge back with the --reintegrate
option."

As a result the process of merging branch changes back to the trunk will be
very easy: you'll never have conflict markers in files; as your colleague
has latest changes from trunk he can run unit tests in branch and you don't
need to worry that something will not work after merging.
Please, refere to
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commo npatterns.html#svn.branchmerge.commonpatterns.feature,
in order to read more about feature branches.

>It gets complicated, if someone else continues to check things in to trunk
Before merging be sure that you have latest version of trunk, by making
update, and that you don't have any local modifications, so you'll never
have conflict files, it's SVN recommendation. Even if somebody makes commits
to trunk while you're merging, you can make Team/Synchronize and perform all
the steps as you did for it.

Here's a link in SVN book about branching and merging:
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html
Re: Branching/Merging workflow ideas [message #503497 is a reply to message #503464] Mon, 14 December 2009 14:12 Go to previous messageGo to next message
Chris Lercher is currently offline Chris LercherFriend
Messages: 14
Registered: December 2009
Junior Member
Hello Igor,

Igor Burilo wrote on Mon, 14 December 2009 05:52
Hello Chris,

Thanks for sharing your opinion about branching/merging. Please, see my
comments below.

1.

In Merge dialog there's a Browse button, which allows you to easily select
the URL, also it's smart enough to open Select Resource dialog on needed
place, for example, if I work in branch:
http://localhost/repos/first/ProjectsData/Subversive/Project -Foo/branches/br1
and when I press Browse button, Select Resource dialog is opened on
http://localhost/repos/first/ProjectsData/Subversive/Project -Foo and it
would be very easy for you to select a needed branch.
Also URL field is a combo box which remembers previously entered values, so
if you previously made merge for 'demo-ui' you can simply select it from
combo and change 'demo-ui' to 'demo-model'.



Well, I feel that it's not always that easy. Your example is in "Single project" layout, meaning that the trunk and branches are sublevels of the project. However, in my case I need to group several projects together into a "Multi project" layout. So for example demo-ui 1.5 should always be built together with demo-model 1.5.

In this case, it's very easy to enter the wrong directory, like e.g. "http://server1.lan/subversion/demo/branches/fancy1" instead of "http://server1.lan/subversion/demo/branches/fancy1/demo-ui". I know, it's possible to get used to that, but I'd prefer some kind of "compile time safety" here Wink Like I said, it's the smaller issue...

Quote:

Probably, we could list branches/tags for particular project but you can
merge not only from branches/tags, you can merge from any place in
repository, also you may not follow branches/tags structure, so it's not a
universal solution, it'll just complicate UI.


I understand, and you're right, subversion is very, very flexible in this way. However, Subversive already provides some support for project layouts, so it would be great, if that feature would also apply to merging. I think the project layouts suggested by the svn-book are very common, similar to naming an ant build-file "build.xml", and Eclipse recognizing that by default as an ant build-file.

I'll post my answers to the more important second item in a separate post...
Re: Branching/Merging workflow ideas [message #503511 is a reply to message #502884] Mon, 14 December 2009 14:47 Go to previous messageGo to next message
Chris Lercher is currently offline Chris LercherFriend
Messages: 14
Registered: December 2009
Junior Member
Igor Burilo wrote on Mon, 14 December 2009 05:52
Hello Chris,

2.
> I can't perform the workflow that I usually use with "Team ->
> Synchronize". I can't use a Synchronize view that shows me, which changes
> I already accepted, and which ones are still "to do". Also, because I get
> diff conflict markers in my files, I can't debug, and I can't run unit
> tests until I have merged everything from the 75 that Harry changed.

SVN recommends following workflow for branching/merging:
- if you plan to make many changes or these changes are time intensive for
adding new functionality, you need to create a feature branch. This is what
you exactly did and this is good.
- there may be a big challenge to merge changes from the branch back to the
trunk. That's your case. Here's a solution to it proposed by SVN:
"This situation is best avoided by regularly merging trunk changes to the
branch. Make up a
policy: once a week, merge the last week's worth of trunk changes to the
branch.
At some point, you'll be ready to merge the "synchronized" feature branch
back to the
trunk. To do this, begin by doing a final merge of the latest trunk changes
to the branch.
When that's done, the latest versions of branch and trunk will be absolutely
identical except
for your branch changes. You would then merge back with the --reintegrate
option."

As a result the process of merging branch changes back to the trunk will be
very easy: you'll never have conflict markers in files; as your colleague
has latest changes from trunk he can run unit tests in branch and you don't
need to worry that something will not work after merging.
Please, refere to
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commo npatterns.html#svn.branchmerge.commonpatterns.feature,
in order to read more about feature branches.



Yes, I know the suggestion from the book, and I really like the book. But just as I (and many others) aren't satisfied with Subversion's standard "svn update", and therefore use "Team->Synchronize" instead, I'm not fully satisfied with that suggestion either. Yes, it does make things somewhat easier - but it also means, that my colleague that's working on the branch will often have to deal with (smaller, but still maybe serious) conflicts. As he'll also use the merge functionality, he'll be the one who gets the diff conflict markers...

But let's assume, that he did that. Then I will get no conflicts when reintegrating, ok. But it's still very much like an "svn update": It automatically takes all "syntactically non-conflicting" changes into my files. This is just too dangerous for an experimental feature. The preferred way would be to initially not merge any changes at all, and then copy individual changes from the branch into my trunk-workspace. Just like I would when using "Team->Synchronize".

This is much like configuring a firewall: First you close all doors, then you open some, because the other way around is too dangerous. I prefer to have a quite stable trunk, which is the reason I'd like to create feature branches for features that might break something (Another example is switching to a different technology, e. g. from EJB Entity Beans to Hibernate or so.)

Unit tests are very important, but they can't detect design mistakes etc. And there are always problems that you will only see when looking through the code. Things that are extremely hard to spot with Unit tests (things like: Yes, that String verification is taking place correctly, but it's circumvented when the data is loaded from cache... Ah I just implemented the cache in trunk - and my colleague implemented the String verification. The unit tests that we each wrote pass very nicely...)
Re: Branching/Merging workflow ideas [message #503655 is a reply to message #503511] Tue, 15 December 2009 03:54 Go to previous messageGo to next message
Igor Burilo is currently offline Igor BuriloFriend
Messages: 435
Registered: July 2009
Senior Member
Hello Chris,

I undesrtand your point and agree that in some cases it would be great to
make merging bit by bit. We already had such a functionality but starting
from SVN 1.5 we discarded it, because of technical reasons: one of them was
that SVN added merge tracking functionality and on merges it set merge
revisions as properties which means that if Subversive does merge manually
we would need also to set somehow these revisions too which is a complicated
task, in other words we'd need to implement merge by themselfes, so we
decided to discard this functionality.

> Igor Burilo wrote on Mon, 14 December 2009 05:52
>> Hello Chris,
>>
>> 2.
>> > I can't perform the workflow that I usually use with "Team ->
>> > Synchronize". I can't use a Synchronize view that shows me, which
>> > changes I already accepted, and which ones are still "to do". Also,
>> > because I get diff conflict markers in my files, I can't debug, and I
>> > can't run unit tests until I have merged everything from the 75 that
>> > Harry changed.
>>
>> SVN recommends following workflow for branching/merging:
>> - if you plan to make many changes or these changes are time intensive
>> for adding new functionality, you need to create a feature branch. This
>> is what you exactly did and this is good.
>> - there may be a big challenge to merge changes from the branch back to
>> the trunk. That's your case. Here's a solution to it proposed by SVN:
>> "This situation is best avoided by regularly merging trunk changes to the
>> branch. Make up a
>> policy: once a week, merge the last week's worth of trunk changes to the
>> branch.
>> At some point, you'll be ready to merge the "synchronized" feature branch
>> back to the
>> trunk. To do this, begin by doing a final merge of the latest trunk
>> changes to the branch.
>> When that's done, the latest versions of branch and trunk will be
>> absolutely identical except
>> for your branch changes. You would then merge back with the --reintegrate
>> option."
>>
>> As a result the process of merging branch changes back to the trunk will
>> be very easy: you'll never have conflict markers in files; as your
>> colleague has latest changes from trunk he can run unit tests in branch
>> and you don't need to worry that something will not work after merging.
>> Please, refere to
>> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commo
>> npatterns.html#svn.branchmerge.commonpatterns.feature, in order to read
>> more about feature branches.
>
>
> Yes, I know the suggestion from the book, and I really like the book. But
> just as I (and many others) aren't satisfied with Subversion's standard
> "svn update", and therefore use "Team->Synchronize" instead, I'm not fully
> satisfied with that suggestion either. Yes, it does make things somewhat
> easier - but it also means, that my colleague that's working on the branch
> will often have to deal with (smaller, but still maybe serious) conflicts.
> As he'll also use the merge functionality, he'll be the one who gets the
> diff conflict markers...
>
> But let's assume, that he did that. Then I will get no conflicts when
> reintegrating, ok. But it's still very much like an "svn update": It
> automatically takes all "syntactically non-conflicting" changes into my
> files. This is just too dangerous for an experimental feature. The
> preferred way would be to initially not merge any changes at all, and then
> copy individual changes from the branch into my trunk-workspace. Just like
> I would when using "Team->Synchronize".
>
> This is much like configuring a firewall: First you close all doors, then
> you open some, because the other way around is too dangerous. I prefer to
> have a quite stable trunk, which is the reason I'd like to create feature
> branches for features that might break something (Another example is
> switching to a different technology, e. g. from EJB Entity Beans to
> Hibernate or so.)
>
> Unit tests are very important, but they can't detect design mistakes etc.
> And there are always problems that you will only see when looking through
> the code. Things that are extremely hard to spot with Unit tests (things
> like: Yes, that String verification is taking place correctly, but it's
> circumvented when the data is loaded from cache... Ah I just implemented
> the cache in trunk - and my colleague implemented the String verification.
> The unit tests that we each wrote pass very nicely...)
Re: Branching/Merging workflow ideas [message #503657 is a reply to message #503497] Tue, 15 December 2009 04:14 Go to previous messageGo to next message
Igor Burilo is currently offline Igor BuriloFriend
Messages: 435
Registered: July 2009
Senior Member
Hello Chris,

> Well, I feel that it's not always that easy. Your example is in "Single
> project" layout, meaning that the trunk and branches are sublevels of the
> project. However, in my case I need to group several projects together
> into a "Multi project" layout. So for example demo-ui 1.5 should always be
> built together with demo-model 1.5.
>
> In this case, it's very easy to enter the wrong directory, like e.g.
> "http://server1.lan/subversion/demo/branches/fancy1" instead of
> "http://server1.lan/subversion/demo/branches/fancy1/demo-ui". I know, it's
> possible to get used to that, but I'd prefer some kind of "compile time
> safety" here ;) Like I said, it's the smaller issue...

I just gave an example with single project layout to demonstrate that Browse
button is smart enough to open Select Resource dialog on project level but
not, for example, on repository root level, so you don't need to browse
whole repository starting from repository root to point to your branch; the
same applies also for multi project layout. So Browse button already takes
into account project layout.
Re: Branching/Merging workflow ideas [message #503667 is a reply to message #503657] Tue, 15 December 2009 09:29 Go to previous messageGo to next message
Chris Lercher is currently offline Chris LercherFriend
Messages: 14
Registered: December 2009
Junior Member
Igor Burilo wrote on Mon, 14 December 2009 23:14

I just gave an example with single project layout to demonstrate that Browse
button is smart enough to open Select Resource dialog on project level but
not, for example, on repository root level, so you don't need to browse
whole repository starting from repository root to point to your branch; the
same applies also for multi project layout. So Browse button already takes
into account project layout.


Yes, and this already helps very much Smile

I'm not sure, what's that setting in "SVN Repositories -> Location Properties -> Advanced", where it says "Enable Structure Detection", and you can give the resource names for Trunk, Branches and Tags?
And the one in "Preferences -> Team -> SVN -> Repository", und "Branch and Tag Settings", which says:

"There are two ways how to define a location of a branch (tag), ..."

I just thought, that these settings would provide some hint to the merge view, but I'm really not sure, if I understand the settings correctly.
Re: Branching/Merging workflow ideas [message #503672 is a reply to message #502884] Tue, 15 December 2009 09:46 Go to previous messageGo to next message
Chris Lercher is currently offline Chris LercherFriend
Messages: 14
Registered: December 2009
Junior Member
Igor Burilo wrote on Mon, 14 December 2009 22:54
Hello Chris,

I undesrtand your point and agree that in some cases it would be great to
make merging bit by bit. We already had such a functionality but starting
from SVN 1.5 we discarded it, because of technical reasons: one of them was
that SVN added merge tracking functionality and on merges it set merge
revisions as properties which means that if Subversive does merge manually
we would need also to set somehow these revisions too which is a complicated
task, in other words we'd need to implement merge by themselfes, so we
decided to discard this functionality.



Hello Igor,

you mean, it was already there? Oh no! But I understand your point: I'm not very familiar with merge tracking, but I think it's a very complex topic.

In this case, I think the merge functionality should stay as it is right now, because it's really much better to let svn perform that tracking.

But then I have an alternative idea: We should have a "Team -> Synchronize with another Branch" or similar!
I mean, we have "Team->Update" now, which performs an "svn update". We have "Team->Merge", which performs an "svn merge". And we have "Team->Synchronize with Repository" that allows me to do bit-by-bit merging from the latest revision of the resource's *current* branch (or trunk). But what's really missing is the bit-by-bit merging from the latest revision of a *different* branch. This would need no merge-tracking, because from svn's perspective, it's like manually applying patches without using svn. (Similar to what happens now with "Team->Synchronize with Repository", right?)

What do you think?
Re: Branching/Merging workflow ideas [message #504103 is a reply to message #503667] Thu, 17 December 2009 09:25 Go to previous messageGo to next message
Igor Burilo is currently offline Igor BuriloFriend
Messages: 435
Registered: July 2009
Senior Member
Hello Chris,

Structure settings (trunk, branches, tags) in Preferences(see
Windows/Preferences) are default one; structure settings in Repository
Location properties are specific to particular repository location on which
they're defined. I think it's clear why we need settings in Repository
Locations properties: detecting branches, tags, trunk for repository
location, e.g. they have different images on SVN Repositories view, they're
used for creating branches, tags etc.
We need settings in Preferences for following cases:
- when you create new repository location, values for trunk/branches/tags
are retrieved from Preferences
- there're cases when we need to create repository location programmatically
and values for trunk/branches/tags are set from Preferences, e.g. when we
automatically share new project, we automatically create new location for it
and connect this project to location.

> I'm not sure, what's that setting in "SVN Repositories -> Location
> Properties -> Advanced", where it says "Enable Structure Detection", and
> you can give the resource names for Trunk, Branches and Tags?
> And the one in "Preferences -> Team -> SVN -> Repository", und "Branch and
> Tag Settings", which says:

> "There are two ways how to define a location of a branch (tag), ..."
>
> I just thought, that these settings would provide some hint to the merge
> view, but I'm really not sure, if I understand the settings correctly.
Re: Branching/Merging workflow ideas [message #504106 is a reply to message #503672] Thu, 17 December 2009 04:48 Go to previous messageGo to next message
Igor Burilo is currently offline Igor BuriloFriend
Messages: 435
Registered: July 2009
Senior Member
Hello Chris,

""Team->Synchronize with Repository" that allows me to do bit-by-bit merging
from the latest revision of the resource's" is just a specific case of
Merge, it's like Merge Reintegrate. I don't consider that it's good idea to
add such a functionality only for this specific case; we should add bit by
bit merging either for the whole Merge or not to add it at all; but because
of technical reasons we discarded this functionality.


> But then I have an alternative idea: We should have a "Team -> Synchronize
> with another Branch" or similar!
> I mean, we have "Team->Update" now, which performs an "svn update". We
> have "Team->Merge", which performs an "svn merge". And we have
> "Team->Synchronize with Repository" that allows me to do bit-by-bit
> merging from the latest revision of the resource's *current* branch (or
> trunk). But what's really missing is the bit-by-bit merging from the
> latest revision of a *different* branch. This would need no
> merge-tracking, because from svn's perspective, it's like manually
> applying patches without using svn. (Similar to what happens now with
> "Team->Synchronize with Repository", right?)
>
> What do you think?
Re: Branching/Merging workflow ideas [message #504118 is a reply to message #502884] Thu, 17 December 2009 11:00 Go to previous messageGo to next message
Chris Lercher is currently offline Chris LercherFriend
Messages: 14
Registered: December 2009
Junior Member
Hello Igor,

I just found out, that I can use "Compare with...->Branch", which supports most of my needs. I can select a branch easily, and then it displays all the changes in a tree (very nice!), and it lets me perform individual "Copy from right to left" steps.

Unfortunately, I can't mark my files as merged, which makes the whole process a *lot* harder (it's extremely helpful to see which files are still "to do", especially if there are some changes in some files, which I decide not to accept). But for the most part, this allows me to apply bit-by-bit changes.

So I imagine, I will be able to achieve my workflow like this:
- I'm in some branch (or trunk).
- Perform a "Compare with..." with the other branch (or trunk).
- Accept individual changes for some files.
- Commit.
- Perform a "Team->Merge", rejecting all changes (even non-conflicting!).
- Commit again (to apply the merge tracking properties).

I haven't tested this yet, but I hope it will work.

Thanks. I'd be happy to hear additional suggestions!
Chris
Re: Branching/Merging workflow ideas [message #505183 is a reply to message #504118] Mon, 28 December 2009 11:59 Go to previous message
Igor Burilo is currently offline Igor BuriloFriend
Messages: 435
Registered: July 2009
Senior Member
Hello Chris,

This is good that this solution support most of your needs.

> Hello Igor,
>
> I just found out, that I can use "Compare with...->Branch", which supports
> most of my needs. I can select a branch easily, and then it displays all
> the changes in a tree (very nice!), and it lets me perform individual
> "Copy from right to left" steps.
>
> Unfortunately, I can't mark my files as merged, which makes the whole
> process a *lot* harder (it's extremely helpful to see which files are
> still "to do", especially if there are some changes in some files, which I
> decide not to accept). But for the most part, this allows me to apply
> bit-by-bit changes.
>
> So I imagine, I will be able to achieve my workflow like this:
> - I'm in some branch (or trunk).
> - Perform a "Compare with..." with the other branch (or trunk).
> - Accept individual changes for some files.
> - Commit.
> - Perform a "Team->Merge", rejecting all changes (even non-conflicting!).
> - Commit again (to apply the merge tracking properties).
>
> I haven't tested this yet, but I hope it will work.
>
> Thanks. I'd be happy to hear additional suggestions!
> Chris
Previous Topic:Right bar in compare does not work same as in editor
Next Topic:Repo deleted files not shown as incoming change
Goto Forum:
  


Current Time: Fri Nov 28 13:45:06 GMT 2014

Powered by FUDForum. Page generated in 0.05072 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software