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

[Lev Serebryakov <le...@serebryakov.spb.ru>]

Hello Mats,

Thursday, November 13, 2003, 11:28:03 AM, you wrote:

MN> I don't understand your point. Why aren't you allowed to have multiple
MN> tags on the same version? It's a very, very common use case.
  You could have multiple TAGS on one REVISION. But you could not have
  one TAG on multiple BRANCHES IN ONE FILE (yes, one file could have
  tag on one branch, and other -- on another, it is allowed). Tags are
  created with COPY operation in subversion, and if here is many
  possible parents for tag, script DON'T KNOW, which TREE it should
  copy to create this tag.

MN> A branch is unambiguously defined by its revision number (e.g
MN> 1.24.0.22). Specifically, it is not defined in terms of other tags. IMO,
MN> a conversion script should not depend on that, or it will not be useful
MN> for a great number of well-formed CVS repositories.
  Tag always is set on some branch. And tag created with COPYING.

MN> As for synthetic test cases, this is in fact a fragment of a real world
MN> repository. Every file is not changed for each release. This means that
MN> for some files, there will be many tags on some versions.
  Script gather information form ALL files. And this allow to decide,
which branch (trunk is special branch, of course) should be copied
to create tag. Script don't work on per-file basis, it try to
reconstruct FULL tree of branches and tags on them. It NEEDS this
information, because tag creation process is not `put into SVN
repository THIS revision of this file and THAT revision of that
file', but it is `COPY this tree in that moment of time'. So, script
should now WHICH tree it should copy/ And when tag could be created
with copying any of 4 trees (branches), for example (because all
these branches are equial in given moment of time), it ask for help
from user, because it COULD NOT decide, which branch is PROPER to
copy into tag (or new branch).

  Ok, I could add DUMB mode, when tags and branches will be created not
with cheap copy operations, but with ADDING files to repository. Then
no conflicts will be detected and every situation will be resolved
WITHOUT user interaction. But this will lead to situation, when each
branch or tag consume full space in repository, history on these files
will be lost, etc, etc, etc. Do you need it? It could be added in 10
minutes!

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

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

[Mats Nilsson <ma...@xware.se>]

Lev Serebryakov wrote:
> Thursday, November 13, 2003, 11:28:03 AM, you wrote:
> 
> MN> I don't understand your point. Why aren't you allowed to 
> have multiple
> MN> tags on the same version? It's a very, very common use case.
>   You could have multiple TAGS on one REVISION. But you could not have
>   one TAG on multiple BRANCHES IN ONE FILE (yes, one file could have
>   tag on one branch, and other -- on another, it is allowed). Tags are
>   created with COPY operation in subversion, and if here is many
>   possible parents for tag, script DON'T KNOW, which TREE it should
>   copy to create this tag.

That is fair. But if the situation should appear, then the conversion
script could take steps to faithfully reproduce at least HEAD for each
tag, resorting to deletions and selective copies if necessary.

> MN> A branch is unambiguously defined by its revision number (e.g
> MN> 1.24.0.22). Specifically, it is not defined in terms of 
> other tags. IMO,
> MN> a conversion script should not depend on that, or it will 
> not be useful
> MN> for a great number of well-formed CVS repositories.
>   Tag always is set on some branch. And tag created with COPYING.

I don't understand this comment.

> MN> As for synthetic test cases, this is in fact a fragment 
> of a real world
> MN> repository. Every file is not changed for each release. 
> This means that
> MN> for some files, there will be many tags on some versions.
>   Script gather information form ALL files. And this allow to decide,
> which branch (trunk is special branch, of course) should be copied
> to create tag. Script don't work on per-file basis, it try to
> reconstruct FULL tree of branches and tags on them. It NEEDS this
> information, because tag creation process is not `put into SVN
> repository THIS revision of this file and THAT revision of that
> file', but it is `COPY this tree in that moment of time'. So, script
> should now WHICH tree it should copy/ And when tag could be created
> with copying any of 4 trees (branches), for example (because all
> these branches are equial in given moment of time), it ask for help
> from user, because it COULD NOT decide, which branch is PROPER to
> copy into tag (or new branch).

Well, I argue that for my repository, if there exists alternative
solutions, and if all are equivalent and correct, you should simply
choose one of them.

>   Ok, I could add DUMB mode, when tags and branches will be 
> created not
> with cheap copy operations, but with ADDING files to repository. Then
> no conflicts will be detected and every situation will be resolved
> WITHOUT user interaction. But this will lead to situation, when each
> branch or tag consume full space in repository, history on these files
> will be lost, etc, etc, etc. Do you need it? It could be added in 10
> minutes!

No, please don't. I still think there exists a solution. I guess the
cvs2svn.py and vcp efforts would already have complained about these
problems if they weren't resolvable, at least approximately resolvable.

(Well, cvs2svn.py doesn't handle this repository fragment either, so I
might stand corrected in the long run. :))


Mats


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org