Just a question: regardless of the granularity of the changeset or package,
how dependent are they of earlier changesets?
Can I grab the latest set from the svn repository witout updating to
all that was commited before?I suppose not since it would allow me to break
what the current commiting model tries to ensure:that the tree is 'sane'.
But a way to get changes selectively would be very beneficial.
Is this on the developers agenda?
I'd like to hear the usual answer to my newbie questions:"yes we have this
you just didn't read the whole documentation" :)
> kbrannen@gte.net wrote:
>
> > This has been a very intersting thread to read, but the above has me
> > puzzled. I'm wondering if multiple definitions of "changeset" are in
> > use. A little googling has led me to:
> >
> > ... changes to multiple files into a single unit of work (a changeset)
> > that is itself revision-controlled. (from the BK site incidently)
> >
> > The way I read the above (and a few other posts), it appears that a
> > different definiton is in use because it appears to me that SVN
> > already does this, yet some posts (e.g. the quote above) discuss SVN
> > like it doesn't.
> >
> > Can someone help my confusion? :-)
>
>
> A changeset is that, yes -- but there's more. The main feature of a
> changeset engine is that it manipulates individual changes in a
> changeset as first-class objects. A "change" in this context is not
> limited to the granularity of a file: you can have several changes (call
> them diff hunks, if you like) in a single file, and a changeset engine
> will track each of them separately.
>
> What Subversion handles today has been called "change packages" rather
> than changesets: A change package is a set of changes to a set of files,
> treated as a unit. The main difference is that unlike with changesets,
> the basic unit of granularity in a change package is the file.
>
> --
> Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 16 10:04:50 2002