So if I understand correctly, you're suggesting merging every "safe" change
from trunk to branch every time any change is made, throughout the whole
development cycle, OR, retrospectively going back through all the changes
and merging the safe ones over 1 by 1. I have a few questions about this
method:
If I make an unsafe change for testing to the trunk, then I make a 2nd
unsafe change to that file, then testing verifies that the file is now safe,
I need to go back and merge both changes to the branch - I can't just merge
1 change. I don't know if this becomes tricky with many changes - is it easy
to merge a commit along with all previous changes to that file since
revision X?
For example, this means that even if only 1 file has been changed (and we
change it once a day for 150 days), I need to merge 150 changes rather than
just adding 1 file, which seems kinda wasteful to me - if there's a way
around this it would be much appreciated.
If I use this method (retrospectively going back and merging all the changes
across to a stable branch), I've got around 600 commits to go through and
merge - it would certainly be helpful if I could cut that number down by
removing commits that are changing the same file (and by merging the highest
commit, it merges all commits to that file since revision X, and then
removes those commits from the list to parse).
I don't suppose there is a method of merging commits into one commit? E.g.
revision 9238 is feature X, 9245 is fix for feature X, 9249 a tweak for
feature X, then merge all 3 of those commits into revision 9249? Something
that could be done along the development process, tagging a commit as part
of an ongoing feature. (this would also make viewing version history /
feature tracking a lot easier rather than being spammed by various bugfixes,
feature tweaks, balance tests, etc)
Thanks,
Mike
Stefan Kueng wrote:
>
> AfterShock wrote:
>> Yes, I want to create a zip file for users to install as a patch. But we
>> don't want to release the patch just yet. There are certain files and
>> changes in the HEAD trunk which are unfinished features which need
>> removing
>> from the patch. Ideally I would like the whole team to be able to remove
>> their unfinished features from the patch branch themselves. With the
>> system
>> you propose, I would have to do this myself by removing the local files
>> manually from the exported folder.
>>
>> I guess you could perhaps argue that each feature should be on it's own
>> branch until it's definitely ready for inclusion, making trimming
>> unfinished
>> features at patch-time very easy. But this would make testing very hard
>> as
>> all my team want to be working on the same checkout, as we test many
>> different features at the same time - we wouldnt want to be switching
>> from
>> branch to branch to test each feature.
>>
>> I would also like a history of any files added / deleted to the patch,
>> which
>> is not possible if I am simply modifiying an unversioned local folder
>> made
>> from the exported modified files.
>>
>> Ideally I would like to have a "release candidate" branch which contains
>> the
>> contents of the patch zip file for testing. My team would then check this
>> branch out, copy all the files over to a "Current release (2.1)" folder
>> and
>> see if everything works ok, and can add / remove files.
>>
>> In short, I'd like all my team to have read / write access to the patch
>> zip
>> file while it is under construction.
>>
>> Does this mean I should create a branch, create a local export of all the
>> changed files, and then SVN delete every file from the branch which is
>> not
>> on that list. Are there any better methods or am I missing something
>> still?
>
> * work on trunk with the whole team
> * make a release tag for the first *released* version
> * create a 'stable' branch from that release tag
> * keep working on trunk, introduce new features, fix bugs, ...
> * after fixing a bug on trunk, merge that revision back to the stable
> branch
> * keep merging back bugfixes to the stable branch from trunk
> * when you think you're users want to try a patch:
> - show log for the stable branch, check "stop on copy/rename"
> - select the first revision (where the branch was created) and the
> last revision, right-click, choose "Compare revisions"
> - select all files in the "changed files" dialog, right-click,
> choose "export selected files to..."
> - zip the exported files, send the zip to the user(s)
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
> ------------------------------------------------------
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=993800
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe_at_tortoisesvn.tigris.org].
>
>
--
View this message in context: http://www.nabble.com/How-to-delete-all-unmodified-files-between-2-revisions-on-a-patch-branch--tp21184310p21186374.html
Sent from the tortoisesvn - users mailing list archive at Nabble.com.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=993818
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2008-12-27 19:29:03 CET