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

Re[6]: cvs2svn.pl 0.50 released: first public release

From: Lev Serebryakov <lev_at_serebryakov.spb.ru>
Date: 2003-11-13 13:07:11 CET

Hello Mats,

Thursday, November 13, 2003, 2:46:37 PM, you wrote:

>> file1.c:
MN> Guess you mean file2.c.
  Yes, my fault.

>> REL1:1.2
>> REL2:1.4
>> BRANCH1:1.5.0.2
>>
>> If script sees only `file1.c' it "thinks":
>>
>> (1) REL1 is tag on TRUNK, we copy TRUNK to create it
>> (2) REL2 is tag on TRUNK OR BRANCH1 before file was changed on this
>> branch. WHAT SHOULD WE COPY!? BRANCH1 and TRUNK contains SAME
>> file in this moment of time!
MN> I'd say REL2 is a tag on TRUNK, since its version only has two
MN> components. A tag on BRANCH1 would have a version number 1.3.2.x.
  NOT, NOT AND NOT. When you set tag on file, which is checked out
  from branch, but was not changed on this branch, tag will be set to
  branch point revision. Tag was set ON BRANCH (for all files), but on
  THIS ONE FILE (not changed on branch) it will be on TRUNK revision,.

MN> If I converted this repository (consisting of only file1.c) to svn, I'd
MN> expect to see something like this:
MN> rev 1: A /trunk/file1.c (1.1)
MN> rev 2: M /trunk/file1.c (1.2)
MN> rev 3: M /trunk/file1.c (1.3)
MN> rev 4: A /branches/BRANCH1 by copying /trunk@3
MN> rev 5: A /tags/REL1 by copying /trunk@1
  Why not copy /branches/BRANCH1@4 here? They are equal and consist of
same revision of this file! Why trunk is much important, than
branch?! May be this tag was created on branch, but before first
change of this file on this branch (it is possible).

  Result will be the not same, because, when you copy from branch, you
copy log message about branch creation too. It could be important. If
it is not important for you, read about `-w' option and
`DiffSymParents' event.

  In some cases, `-sh' option could solve such ambiguous situations,
but only in case when tags on branches starts with branch names... It
is simple heuristic, but it works for FreeBSD repository, for example.

MN> For a repository with both files, it might read:
MN> rev 1: A /trunk/file1.c (1.1)
MN> A /trunk/file2.c (1.1)
MN> rev 2: M /trunk/file2.c (1.2)
MN> rev 3: M /trunk/file1.c (1.2)
MN> M /trunk/file2.c (1.3)
MN> rev 4: M /trunk/file1.c (1.3)
MN> M /trunk/file2.c (1.4)
MN> rev 5: M /trunk/file2.c (1.5)
MN> rev 6: A /branches/BRANCH1 by copying /trunk@5
MN> rev 7: A /tags/REL1 by copying /trunk@2
MN> Look for a copy source with revisions file1(1.3) file2(1.4):
MN> rev 8: A /tags/REL2 by copying /trunk@4
  Yes, script will do exactly this work in such case.

MN> Lev, it would be really interesting if you could extend this example in
MN> such a way that the choices in the first walkthrough would not be
MN> equivalent. That could maybe help to illustrate your point.
 If script have two equivalent choices (as in eexample with only
 file1.c) it could not choice anything/ because it don't have
 additional information for choice, and I don't want to do RANDOM
 choice. You could help scrpt with `-sp' option or allows random
 choice with `-w DiffSymParent' option.

-- 
Best regards,
 Lev                            mailto:lev@serebryakov.spb.ru
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 13 13:07:44 2003

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.