2009/4/27 Mike Meyer <mmeyer_at_lexmark.com>:
>
> marc gonzalez-carnicer <carnicer.lists_at_gmail.com> wrote on 04/25/2009
> 05:05:55 AM:
>
>> hi,
>>
>> 2009/4/24 Mike Meyer <mmeyer_at_lexmark.com>:
>> >
>> > marc gonzalez-carnicer <carnicer.lists_at_gmail.com> wrote on 04/24/2009
>> > 07:57:57 AM:
>> >
>> >> hi Mike,
>> >>
>> >> thanks for your email. your idea is fine, but that's not be what i
>> >> asked. perhaps there are some revisions that i may want to exclude on
>> >> purpose, either temporarily or forever. hence the email subject,
>> >> "cherrypicking".
>> >
>> > You're right, it doesn't answer the question you asked; I saw that that
>> > had
>> > already been answered (you weren't doing anything wrong, that's the way
>> > SVN
>> > works), and was trying to offer a better solution to your problem.
>>
>> actually, because of the chaos caused by the multiple merge operations
>> triggered by my single command, before posting i had done as you
>> suggested : merge all the trunk into the feature branch, then merge
>> back, not copy (a copy / overwrite may not take care of added and
>> specially deleted files).
>
> Yup; that's actually what I meant. I'm used to the P4 terminology, where
> copy is a special case of merge, not a seperate command. Sorry 'bout the
> confusion.
ok, no problem -- don't know what P4 is :)
>
>> i can agree with your definition that when something makes your life
>> difficult, that is probably a bad idea to do. however, i do strongly
>> believe that merging back a feature branch into the trunk should be
>> something easy and smooth, as long as development in both branches has
>> been done with a minimum care.
>
> Maybe the people I work with (including me) just aren't careful enough - the
> only merges that are reliably "easy and smooth" are the ones that are "make
> this branch look exactly like that branch". Which is why I try to arrange
> things so that's what merges to the trunk look like.
even if one tries to be careful (taking care with well written log
messages, etc), it's
still easy to make mistakes.
>> the fact that multiple revision ranges merging is performed in
>> multiple steps does not always allow for trouble free merging back.
>> that's a feature i was used to in an old, now deprecated VCS named
>> sccs (used by sun's teamware), that is fundamental for team
>> development.
>
> Would that be the same SCCS that Bell Labs shipped with several versions of
> Unix? Until it was displaced by the (license-free) RCS from Purdue? Neither
> of which properly supporte distributed development?
i have never been user of commercial unix besides solaris / sunos, but
i guess so. i was
amazed to find some old sun manuals where i could see it was first
developed in the
early 70s with a well-defined mathematical model.
sun replaced SCCS / teamware by CVS sometime around 2002, so we had to
be very careful not to lose the original CDs and their development
enviroments. we
realized that around 2004 and that's when i started to look for VCS
alternatives, and
i found out svn existed.
i'd say it should be somehow possible to do distributed development
with SCCS teamware. you
need to "bringover create" (svn checkout) or "bringover update" (svn
update) on a mounted
disk of the "parent" repo, and if you can physically take that disk to
your second development
environment it's fine. then in order to merge changes you would need
to mount back the disk
onto the first machine. but i never tried that.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1959277
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-28 08:32:43 CEST