On Wednesday 23 August 2006 19:01, John Doisneau wrote:
> Hello
>
> I have a question that I have been wanting for quite a long time - I
> hope I will write it clearly enough.
Hello John.
I hope to do the same. (I'm new to the list)
[...]
> Let's say that I organized my day such that I worked the first couple
> hours of the day on FunctionalityA, then I switched to BugB until the
> middle of the afternoon, and then I went back to FunctionalityA, such
> that at the end of the day I have completed those 2 tasks - ie my
> changesets are ready to be commited to the SVN repository.
You shouldn't. IMHO it's better to done one thing right.
You could also create two branches and then merge them. But it could
be an overkill, or the right thing to do, depending on your policies.
> Now I would like to commit my code in such a way that it is possible
> later for somebody to quickly see and take all the changes made to
> implement FunctionalityA, and separately to correct BugB. How do I
> perform this commit action?
>
> If the changesets were not having some files in common, I could easily
> commit in two steps:
> 1) commit the files of FunctionalityA
> 2) commit the files of BugB
Right.
> Now you see that my problem is that the two changesets have some files
> in common, so what can I do there? I cannot select part of a file and
> commit just that part under TAG_FCT_A or TAG_BUG_B.
AFAIK no.
I know that darcs, mercurial and svk have this feature (in svk is a new
feature, no so stable)
> Would somebody have a suggestion to keep our organization in separate
> changesets?
Simply start doing one thing right.
Daniele P.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 23 20:02:05 2006