[PATCH 2 of 2 rfc] subrepos: make subrepositories sticky

[timeless]

On Tue, Jan 25, 2011 at 4:03 PM, Erik Zielke <ez at aragost.com> wrote:
> Yes, but my problem is, that I am not sure what the hint should be, as in
> not only from a language point of view, but what the user should be
> recommended to do.

sure, but an XXX will call attention to the problem from reviewers
(martin, myself) (as will the overly long message since Martin will
object to that). The more information available in the string
initially, the more likely we are to be able to give you a condensed
recommendation.

Basically, i'm not asking for you to write the final hint, i'm asking
for you to hint to someone like me what info you have that I could
choose to provide in that final hint. but save me the effort of
reading the whole patch, whole module and understanding the thing.

> I guess something very similar should be recommended for a git
> subrepository, as in commit and merge with intended revision. But I don't
> know what should be recommended for subversion repositories, when a user has
> checked out an earlier revision and then made some changes in the working
> copy.

i guess the right "svn" thing to do is to create a branch (svn copy to
/branches/) and later merge. The right thing to do for most places is
a rebase.

I think that in general svn would probably refuse the commit as "not current".