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

Re: How to delete all unmodified files between 2 revisions on a patch branch?

From: Stefan Kueng <tortoisesvn_at_gmail.com>
Date: Sat, 27 Dec 2008 18:27:39 +0100

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].

Received on 2008-12-27 18:27:56 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.