On 10/12/06, Ed S. Peschko <esp5@pge.com> wrote:
> ok, but if you said something like:
>
> svn commit (list of files) --name 'my_changeset'
>
> wouldn't it be possible to store the named changeset on the server, rather than
> relying on the number of the changeset?
Yes, it would, but the subversion server already assigns a permanent
global changeset number to the commit. It *could* also attach a
human name to the commit... but the number is usually all one needs.
>
> Suppose I'm an administrator.
> Someone checks in, on a branch, four changesets with:
>
> svn commit --name 'my_changeset' a b c
> svn commit --name 'my_changeset2' d e f
> svn commit --name 'my_changeset3' g h i
> svn commit --name 'my_changeset4' j k l
>
>
> As an administrator, I now want to apply these changesets to the trunk. I don't
> have access to the working copy of the developer who checked these in, and hence
> don't have access to their metadata.
You have the complete history of the repository at your fingertips:
every changeset ever committed by every developer is browseable.
Choose the ones you want, and tell 'svn merge' to merge exactly those
commit numbers.
In other words, subversion already does what you want in this
scenario. It's just using global numbers to refer to committed
changesets, rather than human-invented names. Perforce is the same
way.
> > This scenario is fantasy. :-) Neither perforce nor subversion are
> > able to associate a file with more than one changeset at a time.
> > Sorry!
>
> well, its not fantasy wrt Clearcase. At least that is their claim; that you
> can create multiple changesets containing the same files. And I think that
> bitkeeper may be able to do this as well, although I'm not sure about that.
>
I don't know Clearcase well, maybe someone can speak up on that.
>
> And as long as the changesets are logically distinct, I don't see why this would
> be impossible to do.
Yes, it's certainly a doable thing. It involves making the working
copy sophisticated enough to specify that 'this changed hunk here' is
part of one changeset, and 'this other changed hunk there, in the same
file' is part of a different changeset. Perforce and subversion only
track changesets at the file-level, but yes, it's conceivable that a
higher-resolution system could be written to associate 'hunks' rather
than files. No argument there.
Keep in mind that I'm just talking about managing overlapping
changesets within a working copy. It's a very common thing that two
changesets committed at different points in history affect the same
file. And as you've already said, the order in which you merge those
changesets starts becoming important. That's already the case with
subversion.
> Its not too much for to ask a source control tool to give you a road map
> of what's going on, what has or has not been committed. I don't even think
> it would be that bad, scalability-wise.
Yes, it's bad scalability-wise. Try using that model with thousands
of engineers. It doesn't scale. Trust me. :-) Dozens? No problem.
You need to understand where Subversion is coming from: like CVS,
it's designed for use by untold thousands of anonymous users. The
idea of managing/tracking every working copy is sort of a bizarre
requirement in the world of open source, where who knows how many
hundreds of users are toying with the code, hacking on it, etc.
In a corporate environment, sure, it's nice to keep tabs on your team.
But there are many other ways of doing that. Folks have already
suggested having coders do their work on private branches. That's a
great technique.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 13 01:39:02 2006