[svn] Branches, going back...
Marc Boyer
up to now, I was a "basic" svn user. But, now, I have
a problem.
Here is my problem: up to revision 10, all is going
wright.
At this time, a decide to change some data structure in
my code, it seems ok, I commit version 11, and now, after
some more work, I realise that my change was a mistake,
and I would like to "come back" to revision 10, and
transform the revision 11 as an "experimental" branch.
Is there a way to "come back" ?
Thank you,
Marc Boyer
Bruce Stephens
[...]
> Is there a way to "come back" ?
Yes.
<http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.undo>
Marc Boyer
Thank you.
Marc Boyer
Marc Girod
wrote:
> >> Is there a way to "come back" ?
>
> > Yes.
>
> ><http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#sv...>
It is not exactly a way to come back,
rather a way to fake it.
It will create a new version, meant to be identical to the previous,
will it not?
Does it matter? Well...
- Nothing matters, unless you care
- It depends upon what 'identical' means and for whom
- If you record dependencies, you still need a system to guarantee you
this identicality.
Marc
Bruce Stephens
> On Mar 26, 2:24 pm, Marc Boyer <Marc.Bo...@enseeiht.yahoo.fr.invalid>
> wrote:
>
>> >> Is there a way to "come back" ?
>>
>> > Yes.
>>
>> ><http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#sv...>
>
> It is not exactly a way to come back,
> rather a way to fake it.
>
> It will create a new version, meant to be identical to the previous,
> will it not?
Yes.
> Does it matter? Well...
> - Nothing matters, unless you care
> - It depends upon what 'identical' means and for whom
> - If you record dependencies, you still need a system to guarantee you
> this identicality.
What alternative would you suggest?
It's possible to remove the later revisions, but (as is common in
modern VCS) it's not the kind of thing you'd ordinarily do (it
involves dumping and then restoring the repository).
Another way would be to branch (I guess in subversion terms "branch")
at the desired revision. You could even use the same path name, that
is if you want to remove revisions 11-14 of /trunk, you could make
/trunk@15 be a copy of /trunk@10. I've no idea how one would do that
using the command line, but presumably it's easy enough. I'm not sure
why one would prefer that to committing a revision which explicitly
reverts the unwanted changes, but maybe history-showing programs (like
"svn log") know how to follow such revision references, so would show
a cleaner history?
Marc Girod
+use...@cenderis.demon.co.uk> wrote:
> What alternative would you suggest?
You may remember my past messages.
What I suggest is more or less documented in the CM Wiki,
say in:
http://www.cmcrossroads.com/cgi-bin/cmwiki/view/CM/YaScmManifesto
It is based on 15 years experience gained mostly on ClearCase,
but on promises which were made in base ClearCase, and have
been denied since then.
> It's possible to remove the later revisions, but (as is common in
> modern VCS) it's not the kind of thing you'd ordinarily do (it
> involves dumping and then restoring the repository).
I believe that a 'modern VCS' is an oxymoron,
unless you understand 'modern' from the postmodern view
that this is the now obsolete way people thought until
Darwin, Heidegger and Goedel.
I.e. in a postmodern SCM, the VCS part counts for 1%.
What is important are executables that you can run, and
only in extreme cases will you get back to some level of
sources.
Er... sure: I do *not* mean to remove history.
Only to point back at what was there before.
This is what labels should do (and tags don't).
> Another way would be to branch (I guess in subversion terms "branch")
> at the desired revision.
Create some more data anyway, i.e. make the whole
picture mode redundant, more complex.
Subversion is like Wikipedia one of the tools which
killed Open Source, by blocking the way.
They are free of charge tools, not tools which make
you free.
Sorry, I don't want to try to be practical today.
Or not more than with: drop subversion (together with
UCM, SAP, Wikipedia, PowerPoint, and similar
horror stories of our times).
Marc
Bruce Stephens
[...]
> Er... sure: I do *not* mean to remove history.
> Only to point back at what was there before.
> This is what labels should do (and tags don't).
That's what the subversion example would be doing: you create a
revision @15 (say) that is a copy from @10 (say). (I don't use
subversion much, so I may be using unsubversiony syntax.)
You're right that subversion doesn't have anything other than that
(there's nothing outside the versioned repository such as labels,
tags, etc.). Arguably that's a feature.
In git branches (and tags) are references to revisions, so as you
suggest you could just reset the branch. (In general that might mess
up anything derived from the original, but in this case we knew there
wasn't anything. And sometimes it's appropriate anyway.)
Marc Girod
wrote:
> That's what the subversion example would be doing: you create a
> revision @15 (say) that is a copy from @10 (say).
No. This is a *copy*. A label is a pointer to the *same*.
You don't grant any importance to the distinction
betwen *same* and *identical*, and neither does subversion.
> You're right that subversion doesn't have anything other than that
> (there's nothing outside the versioned repository such as labels,
> tags, etc.). Arguably that's a feature.
Arguably.
Suppose trying to explain to middle ages people what
is nice in buying plane tickets on the internet.
What is interesting is seldom what you can or cannot
do, but what this might enable or prevent.
> In git branches (and tags) are references to revisions, so as you
> suggest you could just reset the branch. (In general that might mess
> up anything derived from the original, but in this case we knew there
> wasn't anything. And sometimes it's appropriate anyway.)
I have never used git, but I believe it is much saner than
subversion. One could build on top of it.
Maybe also on mercurial, or on some other tools
(maybe cvsnt/evs).
Only, subversion is in the way.
As wikipedia in its domain, and maybe linux in its own.
Successful, but not really good.
What they are preventing is probably of the magnitude
of the industrial revolution.
Free software, as a collaborative culture, needs
management of information, not only control.
Marc