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

Re: Problem mergin moves from different repos

From: Guille -bisho- <bisho_at_eurielec.etsit.upm.es>
Date: 2004-10-18 00:29:20 CEST

> > Of course I see the main problems: If you merge that 'move' then you
> > will not be able to apply later previous changesets to the new
> > repository, because those will try to find the old file name.
> This would happen even in a intra-repository merge, no? I.e., there is
> always the possibility that merging out of order won't work; this is
> just inherent in how merging works and has nothing to do with whether
> the source and target repositories are the same or not...

Oops... I haven't noticed it... :/

And I unfortunatelly what we would like is to avoid that problem, but we
are going to have the same problem with intra-repository merges...

moves and renamos are such a horrible thing for revision systems that
are based on paths of files as IDs...

Our situation is the following: We have several environments,
development, testing and release and we want to commit from time to time
to testing several changes from development to testing when some
changesets correct a bug or implement a feature. After testing they are
eventually moved to release, but the order or the additions to the
development environment is not the same order of deploying on
testing/release, so we have to play a lot with merges, and we don't
wan't to copy the last version of files from devel in the case of a
move, just execute that "move" on testing/release.

Is a very different and strange use-case compared to the normal way of
development in Open Source products. :(

Anyway, we will see how we could overcome our problem treating moves by

> Going back to the hard case, there is one common case I didn't think of,
> which is when applying tags. I.e., when applying a tag you could easily
> end up making a copy of a file/directory that's not based on the most
> recent revision (tags can be created at any time, not just "immediately").
> Thinking more about it, it seems that the "copy from the most recent
> revision anyway" solution is the most appropriate one.

Yeah, for normal use-cases that solution will be very handy...

PEACE!,,,,_ ,,    -=] 18/10/2004 [=-
      .'   )  )
    .'    / _/
     -''  \(ยท>  ::              Say NO!!! to SW PATENTS               :: 
      -`_`   )  ::                EuropeSwPatentFree:                 :: 
bisho!,,''- '   ::      http://europeswpatentfree.hispalinux.es/      :: 
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 18 00:30:40 2004

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

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