Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] SVN as p4 replacement was: SCM perforce replacement was: Re: Grimoire Team Lead vote

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: "sm-discuss AT lists.ibiblio.org" <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] SVN as p4 replacement was: SCM perforce replacement was: Re: Grimoire Team Lead vote
  • Date: Wed, 15 Mar 2006 19:05:35 +0100

On Wed, Mar 15, 2006 at 06:46:25PM +0100, Pieter Lenaerts wrote:
> Op wo, 15-03-2006 te 18:11 +0100, schreef Arwed von Merkatz:
> > On Wed, Mar 15, 2006 at 04:52:12PM +0100, Pieter Lenaerts wrote:
> > > Op wo, 15-03-2006 te 15:23 +0100, schreef Arwed von Merkatz:
> > > > > subversion does not remember history across branches:
> > > > > 1..N changes to devel -> merge to test -> leaves only the merge in
> > > > > test's history. imo this is not a problem: we keep our own
> > > > > changelogs in
> > > > > HISTORY, of which we will find the diffs in the logs of devel
> > > > > branch.
> > > >
> > > > That's really not the problem. The problem is that, once you do more
> > > > changes to devel and try to merge them, you get conflicts because
> > > > subversion forgot that you already merged the old ones. This is the
> > > > single biggest problem subversion has in my opinion (not only for
> > > > grimoire work).
> > >
> > > so:
> > >
> > > edit devel, submit
> > > merge to test, submit
> > > edit devel, submit
> > > merge to test gives conflict (?)
> > >
> > > this scenario works perfectly for me, so could you give me the exact
> > > steps you take? you probably gave it the wrong revision keywords
> >
> > The point is that it requires revision numbers on subsequent merges. In
> > any scenario except a direct "submit to devel, merge to test", you don't
> > know previous revision numbers. I know it can be made to work (though I
> > get conflicts even with revision number based merging on my vendor
> > branch tree at uni), but it's quite a bit more handwaving than is
> > necessary with perforce or any other scm that tracks merge history.
>
> no it doesn't require numbers. it requires revision keywords, given that
> noone else has changed the file/folder that you want to merge in the
> mean time.
>
> edit devel
> $ svn commit
> $ svn merge -r committed:head devel/section/spell test/section/spell
> $ svn commit
>
> and done :)

This is _one_ merge, now how does this work if several other gurus now
edit the spell in devel, then I want to integrate that new version to
test?

> I admit that this -r option with argument takes more typing, but you can
> always set an alias (like me), or we could provide one somehow or
> whatever.
>
> (I also admit that it took me quite some attempts before I realized it
> was this simple)
>
> --
> Pieter Lenaerts
> Source Mage GNU/Linux
>
> http://www.sourcemage.org
> "Linux so advanced it may well be magic"



> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss


--
Arwed v. Merkatz Source Mage GNU/Linux developer
http://www.sourcemage.org




Archive powered by MHonArc 2.6.24.

Top of Page