On Mon, Nov 10, 2014 at 6:16 PM, Jan Nijtmans
wrote:
> 2014-11-10 12:56 GMT+01:00 Baruch Burstein :
> > If a change is made to a file under the tags directory, or a file is
> > added/deleted, the commit that it tagged will be forked (or should it
> > branch?) and a new commit with the changes wil
On Mon, Nov 10, 2014 at 5:16 PM, Jan Nijtmans
wrote:
> 2014-11-10 12:56 GMT+01:00 Baruch Burstein :
> > I don't know how to manage deleted tags.
> This should result in a control artifact in stead of a commit, which
> simply deletes the tag from the referenced commit.
>
@Baruch: such a tag looks
2014-11-10 12:56 GMT+01:00 Baruch Burstein :
> Any changes done outside of the trunk/branches/tags directories will be
> ignored (silently or with a warning)
OK
> A branch/tag that doesn't have an obvious parent checkin to apply to, will
> be applied to the most recent checkin (or should it be the
On Mon, Nov 10, 2014 at 11:46 AM, Jan Nijtmans
wrote:
> Commit 70 moved everything under "/trunk/tkimg/" directly under "trunk". In
> the same commit I added svn properties to other branches, so - indeed -
> this is a challenging test-case. I would expect this single svn commit
> result in 5
2014-11-09 8:45 GMT+01:00 Baruch Burstein :
> I am looking at that commit now. It seems that you changed files within a
> tag. How would you suggest I handle a situation like that? As far as I
> understand, once a revision is "tagged" (that is, copied to the "tags"
> directory), the files in it sho
