On 10/15/05, Jean-Marc van Leerdam <developer@bemy.demon.nl> wrote:
> > constituent path names, log message would be stored as a file in some
> > predefined folder similar to where the TSVN cache file is stored.
> That would mean that they are only available for a single developer
> (since they do not reside in the repository). Is that what you want?
Yes, the design goal was to enable the developers to manage the files
they are working on in a better way. Obviously, if the changesets are
to be visible to everyone then this has to be a feature in the SVN
server (similar to Perforce changelists).
> I think it would be more in line with SVN common practice to create a
> separate branch per bug if the development is to take place
> simultaneously.
> Developers can easily switch between branches if they want to work on
> multiple bugs
But then it would be difficult to keep track of the files relevant to
each bug. And if the working copy is huge with lots of small files,
switching/status/update/commit take too long on windows.
> These files probably should not be versioned if that is the case
> (using svn:ignore).
That was just an example i have come across. In that case we have a
file with config params #defined to some values. For
testing/development we sometimes change those values.
> > An initial feedback of the demo from users in our company was very
> positive.
> Were these users experienced SVN users, or are they more experienced
> in other version control systems (like CVS, STAT)
I would say that SVN is their first version control system. Most of
them wanted a workaround for the long time taken while
committing/getting status.
> > 2. Status and commit for the changeset would be *very* fast.
> But there would be no history in the repository about what constituted
> a changeset (especially if the bugfix is committed in several stages).
> If the local storage is lost, the changeset history is lost as well.
The changeset will not have local history. It is only a collection of
files. Users can add/remove files from the collection. On a successful
commit, those many files will constitute the svn revision.
> By the way, if you want the changeset concept to be incorporated in
> SVN you should discuss this on the SVN user/developer list, not the
> TSVN lists (TSVN can only implement what SVN has to offer).
That is true. I was thinking about this as a UI tool to make everyday
tasks easier and efficient.
regards,
aniruddha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Oct 15 14:07:24 2005