Les Mikesell escribió:
Martin Marques wrote:
up side is that you can track development 'forwards' from any point.
Uhh???
$ hg up -r SOME_OLD_REV
Start from a tagged point in development. Branch several times for
different changes. Can you find all subsequent work?
What are you talking about? Do you know that a tag isn't necessarily a
branch (not even on CVS)?
$ cvs tag my_tag
$ cd ../newdir/
$ cvs co -r my_tag myrepo
... change some file....
Now, try to commit the change in the new dir? See? It's a dead end in
CVS too. You need to branch to be able to commit to a *sticky tag*.
The thing is that, for example in Mercurial, branches and tags are
different things, even though the idea is to put a marker at a point and
then start a branch or not.
What? Les do you really know what you're talking about?
I'd like to hear that I don't. With CVS, if you have any of the
development you have all of it. With svn, tags are (by convention) dead
end snapshots and there is no way to track forward development.
I'm not a Subversion expert, only CVS and now Mercurial (not ann expert
yet :-) ).
Assume
you worked on something some time ago, ending by creating a certain tag.
Now several other people create branches for additional work. How can
you tell that, starting from the tag you last knew about? You could
start from any of the branches and work backwards but you can't see what
branches were created or when going forwards.
I don't understand. Where do they branch? On your working branch or
another (like HEAD for example)? BTW different branches mean different
development, or why would you branch?
Remember tags are just a way of marking your development. In CVS you can
tell it to, besides tagging putting a branch which will have the name of
the tag. If you don't branch, you're at a dead end, just like in SVN.
This must be even worse in distributed VC's where the changes might
not even exist in your copy of the repository. Doesn't it bother you
to know you might be repeating someone else's mistakes because you
can't track all the other changes from a given point?
What mistake if it's not in the repository?
That's the point - you won't know.
You can't know in any VCS.
The same thing would happen with CVS if you were coding without
commiting to the main server. Nobody will be able to know what you are
doing. Same if your coworkers don't update regularly. How can they
know what you fixed?
If you aren't committing to the central repository, you aren't using CVS.
I repare a bug, but don't commit, it's the same as commiting to a
distributed VCS and not pushing.
In distributed VCS you use pull and push for this.
How can you tell whether that was always done or not?
By communicatting with the other developers. Or do you work inside a jar?
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
