6 messages in com.perforce.perforce-user[p4] Re: Branching and refactoring| From | Sent On | Attachments |
|---|---|---|
| Ulf | 23 Feb 2004 16:44 | |
| ste...@vance.com | 23 Feb 2004 19:29 | |
| Tyler, Tom | 24 Feb 2004 10:16 | |
| Ulf | 24 Feb 2004 12:57 | |
| Ulf | 24 Feb 2004 13:02 | |
| ste...@vance.com | 24 Feb 2004 14:49 |
| Subject: | [p4] Re: Branching and refactoring |
|---|---|
| From: | Ulf (ul...@ulfkristen.com) |
| Date: | 02/24/2004 01:02:16 PM |
| List: | com.perforce.perforce-user |
Steve,
Now I understand were a branch spec may be useful. I wasn't sure were to use them before. I think they may be handy if for example projA/ need to keep its file/directory names intact, whereas main/ need to contain some renames.
Thanks!
Ulf
steve at vance.com writes:
You do the rename with integ+delete. If you do it on a branch and you want the renamed file to relate to the original, you change the branch mapping to map the main file into the projA file. When you are ready to migrate the changes back, assuming you want the rename to take effect on the return, integ with the modified branch spec, remove the special file mappings, then migrate back. This will ensure that the project has the latest updates to the original, but migrate the rename back when the project returns. You can mitigate the whole problem somewhat by integrating early and often, minimizing the chance of changes to the file between the rename and the return integrate. Note also that if you do integ+integ+...[+delete] to refactor one file into multiple new names, this technique does not work well; you have to choose a single file to map because of the one-to-one requirement.
Steve
Ulf writes:
Hi All,
I'm evaluating Perforce and have a question about branching and refactoring. I've read the "Software Life-Cycle Modelling" paper at the Perforce website and I would like to structure my depot similary, i.e. have to following directories under depot//:
main/ dev/ bugfix/ release/
Development would take place in projects under dev/, for example "dev/projA" and "dev/projB". A project directory would be branched from main when the project is started:
p4 integrate main/... dev/projB/...
When the project is finished it is merged back into main:
p4 integrate dev/projB/... main/...
When experimenting with this setup in Perforce I noticed that renames are not handled very well. For example, suppose "projA/file1.txt" is renamed to "projA/file2.txt", and projA then integrated into main. And suppose projB makes changes to "projB/file1.txt". Then, when projB is integrated into main, main will end up containing both file1.txt and file2.txt. I would have wanted it to contain just file2.txt, but with the changes from projB incorporated.
I searched the archives and noticed that the "rename" operation has been extensively discussed on this mailing list over the years. But it seems that integrate+delete is still the official way to rename a file/directory.
Are people using the above branching strategy? How do you handle renames?
Thanks,
Ulf
_______________________________________________ perforce-user mailing list - perforce-user at perforce.com http://maillist.perforce.com/mailman/listinfo/perforce-user
==================== Stephen Vance http://www.vance.com