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

Re: merging projects

From: Thomas Lehmann <Iris-und-Thomas-Lehmann_at_T-Online.de>
Date: 2006-10-17 15:50:58 CEST
Hi,

Bob Proulx schrieb:
Thomas Lehmann wrote:
  
my question relates to merges:

Every developer is working on a project, that means creating and modifying
some files AND doing some commits at stable phases to be able to undo
implementations - stuff not working as expected.
    

Are developers working on the main trunk or working on a private
branch?
  
private branch!
  http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.patterns

  
Each commit forces a new revision and my question is how to handle
merging all files relating to a project; I want to keep control about what
to merge into the release version and what to keep in the development 
version!
    

I will assume by this that the release version is on a release
branch.  (That does not yet say whether developers work on the main
trunk or on a branch though, just that the release is on a release
branch.)

I don't understand your comment about global version numbers.  Every
commit does increment the repositories last commit revision.  But that
has nothing to do with merging commits to a release branch.  Those are
completely separate concepts.
  
I meant "global" because the revision increases independent of being in main or a private branch!

You can merge whatever you want onto a release branch.  You can merge
everything.  Or you can "cherry-pick" particular changes.  It is all
your choice.
  
Yes - my choice - but it's important how much it costs to do so:

Example:

10 Developers are working more or less independently on their projects and they will continuiously
merging into the development line to keep it up to date. At any time (maybe some months later)
individual developers are told to merge specific projects into the release.
Solutions:
1) Every project is a branch but that does also mean: corrections in the context of an issue tracker
    needing 2 hours of fixing and testing are also a branch  - how many branches has to be managed
    then -> 20, 50, 100, ... 10000 -> Is this what we want to have?
    Advantage: It's much easier to find out what to merge (thanks to the help as explained by last mail)
2) Each developer removes temporary branches after committing and each revision until the
    deletion of a branch must be remebered! (so we can start individual merges) -> many work!!!!

Subversion does not do merge tracking.  Therefore when you merge you
need to manually keep track of what you have merged.  (About this
point someone will mention the "svnverge" script which attempts to
track this with subversion properties.  It seems to work for me in one
direction only.  Perhaps it will work for you.  YMMV.)

  
I've been working on clearcase before and there each "checkout"
forces to select a kind of task the change will refer to. Merging
later on you can select each individual task you like to merge to
another location...  Is this possible with subversion?
    

Yes.  But it is very flexible and all up to you.  It is a little like
asking if you can create files on disk for paricular purposes.  Of
course you can.
  
Hown about the tracking feature? Future enhancement for subversion or always client stuff
like the script you told me?
If you create a branch for every particular task then this would be
very much as you describe.

  svn copy $URL/trunk $URL/branches/task-branch -m "Creating task branch."
  svn switch $URL/branches/task-branch .
  ...edit...test...edit...test...
  svn commit

Now the problem is to merge those changes back into the main trunk.
Did you note down the version when the branch was created?  No?  Then
look for it in the log.

  svn log --stop-on-copy

  svn switch $URL/trunk
  svn merge -r564:579 $URL/branches/task-branch .
  svn commit -m"Merged task-branch changes r564:579 into the trunk."
  
Yes - fine! It sounds reasonable (and the only practicable) but not the best solution I would think about!
I think we can live with it (actually). Could you give a hint on how to reduce the amount of temporary branches?

--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For additional commands, e-mail: users-help@subversion.tigris.org Received on Tue Oct 17 15:50:54 2006

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

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